The use of open source software has grown exponentially in recent years as it makes life easier for developers and users alike. However, the lack of security standards applied to these applications can put users at risk. The Right Way For Securing Open Source Software Act is an important step toward ensuring that open source software is used safely and securely.
The Open Source Software Act would establish standards for all open source project owners to comply with when releasing new software packages or updates. Before any package is released, key components must be tested for vulnerabilities and privacy risks.
Users should also know their rights and responsibilities when using versioned software packages. With the implementation of this act, open source users will know that their security and privacy are taken seriously. Let's learn more about it.
What Is The Open Source Software Act?
On September 21, 2022, the United States Senate saw an unlikely pairing of bipartisanship when Senators Gary Peters (D-MI) and Rob Portman (R-OH), Chairman and Ranking Member of the Homeland Security and Governmental Affairs Committee, respectively, came together to introduce the Securing Open Source Software Act.
Aimed towards safeguarding federal government agencies and their associated infrastructure systems, this act places a strong emphasis on beefing up cybersecurity measures within software. Using this as a stepping stone for creating stronger security protocols, both sides of Congress are coming together in hopes of keeping information secure amid various threats, both domestic and abroad.
“Open source software (OSS) is the bedrock of the digital world, and the Log4j vulnerability demonstrated just how much we rely on it. This commonsense, bipartisan legislation will help secure OSS and further fortify our cybersecurity defenses against cybercriminals and foreign adversaries who launch incessant attacks on networks across the nation.”
– Senator Gary Peters (D-MI), Chair, Senate Homeland Security and Governmental Affairs Committee
Draft Securing Open Source Software Act Of 2022
The draft Act declares its goal to set the official responsibilities of the Director of CISA (Cybersecurity and Infrastructure Security Agency), which belongs to the Department of Homeland Security. Under the competence of both the Office of the National Cyber Director (ONCD) and the Office of Management and Budget (OMB), CISA will be in charge of guaranteeing open source software security. This measure marks an important step forward for cybersecurity regulation, aiming to protect public and private organizations by ensuring adequate security systems.
The Act begins by defining terms like:
The Act then lays out the duties of the CISA Director:
The draft Act adds a subcommittee for “Software security, including open source software security” to the existing Cybersecurity Advisory Committee. The Advisory Committee is tasked to “advise, consult with, report to, and make recommendations to the Director, as appropriate, on the development, refinement, and implementation of policies, programs, planning, and training pertaining to the cybersecurity mission of the Agency.”
The draft Act requires ONCD, OMB, and CISA to issue guidance for Federal agency chief information officers (CIOs) for:
Then the draft Act requires a pilot program to establish an OSPO within at least one Federal agency, that is modeled on OSPOs from the private sector, nonprofits, and academia, to:
What Will The Legislation Do?
Open Source Focus for CISAWith the proposed bill, Cybersecurity and Infrastructure Security Agency (CISA) would be given new duties. CISA, part of Homeland Security, is required to onboard professionals with open source experience as much as permitted. On top of that, the advisory subsection pertaining to open-source security would be housed under CISA's Cybersecurity Advisory Committee. These steps aim to strengthen open source dependence while also raising cybersecurity standards.
1. Open Source Risk Assessment Framework
The Cybersecurity and Infrastructure Security Agency (CISA) is introducing an assessment framework to efficiently tackle open-source code risk. This consolidated effort is built using government, industry, and ecological approaches from software security that focus on optimal results. CISA will bring in automation for gathering open source components used by federal systems at least biannually. They are hoping to extend the same practice for non-federal critical infrastructure systems by executing a pilot program.
2. Federal Agency OSPOs
In an effort to raise the standard for government digitization initiatives, the Act would create a pilot program to introduce Open Source Program Offices (OSPOs) in one Federal agency. With a model inspired by those of private companies, not-for-profit organizations, and institutes of higher education, this movement seeks to implement industry-leading practices established by top-standard institutions. The Office of Management and Budget (OMB) will furnish leaders from all Federal agencies with strategies around open source software use and management that directly reflect evolving best practices from the community at large.
Provisions In The Securing Open Source Software Act
The government's Cybersecurity and Infrastructure Security Agency (CISA) is set to witness an expanding scope of authority if the recently proposed legislation is approved. Aside from overseeing secure software deployment, this would also include oversight of open source software within the software development lifecycle. With this newfound dedication to the protection of secure digital infrastructure, CISA stands ahead of rising cyber threats as part of a greater effort toward ensuring technological stability.
The proposed law directs CISA to create an open source risk assessment framework that should incorporate best practices from the government, private industry, and open source communities. To this end, the framework should consider:
1. Coordination with federal agencies to bolster open source software security.
2. Serving as a public point of contact on open source software security for the state.
3. Local and private entities, assisting with coordinated vulnerability disclosures for open source software and employing individuals with open source expertise and experience.
With these considerations in mind, CISA will be ready to create a robust and comprehensive assessment of risk factors associated with open source components. CISA will consider certain factors when assessing open source software usage. These are:
1. Security properties of code, security practices in code development and deployment,
2. Number and type of vulnerabilities in a software component,
3. Breadth of its deployment,
4. Associated level of risk and the health of the community around it.
After considering these points carefully, CISA will be in a better position to assess all open source software deployed at federal agencies.
Duties And Timelines For Federal Agencies
The Securing Open Source Software Act (SOSSA) has laid out a timeline for the Cybersecurity and Infrastructure Security Agency (CISA) to complete various activities.
1. In the first year, CISA is required to create and make publicly accessible a risk assessment framework.
2. CISA must update this framework annually in case new capabilities or vulnerabilities arise.
3. Within one year of its publishing date and every two years afterward, CISA will perform assessments based on a software bill of materials (SBOMs), software inventories from their agency, and other publicly available information.
4. Within a year of the legislation taking effect, and then every two years after that, Congress will require organizations to submit reports on their use of open source software. These reports should include details about the framework and assessments as part of this new law.
This is all done to ensure the security of any open source software utilized by federal agencies.
What Does The Securing Open Source Software Act mean For Private Entities?
The potential new legislation, while affecting solely federal agencies, still plays an important role in the private sector. This is due to the same issues addressed in the issued self-attestation memo from September 2022 and the noticed cybersecurity executive order of last year; businesses need to abide by these quasi-laws.
Supplying a software bill of materials is just one instance of what must be done for federal sales. What's more, private enterprises are also having to adhere to similar regulations related to SBOMs and software transparency in their own procurement processes.
As technology continues to become more widely used in both the public and private sectors, securing the software supply chain has taken on added importance. This means that companies must be equipped with essential capabilities such as producing system bill-of-materials (SBOMs), understanding the direct and indirect connections of their software, and maintaining highly efficient vulnerability management initiatives. Together, these components form a comprehensive shield to protect vital data held within the software system.
The Problem Of Securing Open Source Software
The security of open source software is a major problem that must be addressed by developers and users alike. With the increasing popularity of open source applications, it is important to understand the risks associated with them, and how to best protect against potential breaches. Some of the problems of securing open source software are:
1. Lack of Security Updates
One of the biggest problems with open source software is that there is no guarantee that security updates will be released on time. When a new security vulnerability is discovered, it is typically up to the community of developers to patch the software. However, many developers do not have the time or expertise to do so, which can leave users vulnerable to attack.
2. Vulnerabilities Are Often Not Patched
Even when security updates are released, they are often not applied in a timely manner. This is because many users do not bother to update their software on a regular basis. As a result, they may remain vulnerable to attack even after a patch has been released.
3. Attackers Can Easily Obtain The Source Code
Another problem with open source software is that attackers can easily obtain the source code. This makes it much easier for them to find and exploit vulnerabilities. Additionally, it allows them to create malware that is specifically designed to target open source software.
4. Users May Be Less Likely To Trust Open Source Software
Finally, users may be less likely to trust open source software due to the fact that it is often developed by volunteers who are not paid for their work. This can make it seem like the software is not as well-made as commercial alternatives
How Can Scantist Help With Open Source License?
1. Scantist helps organizations comply with industry regulations by providing customized visibility into open source license details, so they know exactly what their product or project contains, who owns it and whether modifications need to be made.
2. Furthermore, Scantist allows users to track open source versions over time, ensuring that all components are always up-to-date with the most recent version.
3. Additionally, centralized records can be accessed remotely, allowing teams to securely collaborate on projects even when working remotely.
Related Blogs
Find out how we’ve helped organisations like you
🌟 Celebrating the Success of NTU Cyber Security Day 2024! 🌟
We are excited to celebrate the successful completion of the 2024 NTU Cyber Security Day!
The Urgent Need for Vigilance in the Software Supply Chain
In an era where digital infrastructure underpins nearly every aspect of our lives, from banking, automotive to healthcare, the integrity of our software supply chain has never been more critical. Recent data from cybersecurity experts paints a stark picture: software supply chain attacks are occurring at an alarming rate of one every two days in 2024. This surge in attacks, targeting U.S. companies and IT providers most frequently, poses a severe threat to national security and economic stability.
An Empirical Study of Malicious Code In PyPI Ecosystem
How can we better identify and neutralize malicious packages in the PyPI ecosystem to safeguard our open-source software?