Blogs
Published on
February 17, 2023

The Right Way For Securing Open Source Software Act

5
min read
The Right Way For Securing Open Source Software Act

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?

Open Source

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:

  • Open Source Software means “software for which the human-readable source code is made available to the public for use, study, re-use, modification, enhancement, and re-distribution.”
  • Open Source Software Community means “the community of individuals, foundations, nonprofit organizations, corporations, and other entities that:undefinedundefined
  • Open Source Software Component means “an individual repository of open source software that is made available to the public.”
  • The Act then lays out the duties of the CISA Director:

  • Outreach, engagement, and coordination with Federal and non-Federal entities to strengthen and support the security of open source software.
  • Publicly publish a framework, incorporating government, industry, and open source community frameworks and best practices “for assessing the risk of open source software components, including direct and indirect dependencies.” The framework must incorporate, at a minimum:
  • the security properties of code in a given open source software component, such as whether the code is written in a memory-safe programming language;
  • the security practices of development, build, and release processes of a given open source software component, such as the use of multi-factor authentication by maintainers and cryptographic signing of releases;
  • the number and severity of publicly known, unpatched vulnerabilities in a given open source software component;
  • the breadth of deployment of a given open source software component;
  • the level of risk associated with where a given open source software component is integrated or deployed, such as whether the component operates on a network boundary or in a privileged location; and
  • the health of the community for a given open source software component, including, where applicable, the level of current and historical investment and maintenance in the open source software component, such as the number and activity of individual maintainers.
  • Use the framework to perform a Federal open source software assessment no less than every 2 years. The assessment’s scope will include open source software components used directly or indirectly by Federal agencies based on readily available SBOMs, software inventories, and other accessible data sources. 1. The Act directs CISA to automate the assessment “to the greatest extent practicable” and “publish any tools used to conduct the assessment as open source software.” 2. The Act directs CISA to develop “1 or more ranked lists of components” identified in the assessment, “such as ranked by the criticality, level of risk, or usage of the components, or a combination thereof.” 3. The Act empowers CISA to facilitate sharing the results and datasets publicly, as appropriate.
  • Perform a pilot study of the feasibility of CISA performing the same framework assessment for critical infrastructure entities (outside the Federal government)
  • 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:

  • how CIOs “should, considering industry and open source software community best practices,undefinedundefined
  • how CIOs “should enable, rather than inhibit, the secure usage of open source software at each covered agency”;
  • 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:

  • “support the secure usage of open source software at the covered agency;
  • develop policies and processes for contributions to and releases of open source software at the covered agency, in consultation, as appropriate, with the Offices of General Counsel and Procurement of the covered agency;
  • interface with the open source software community; and
  • manage and reduce risks of consuming open source software at the covered agency.”
  • 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?

    Scantist

    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.

    Scantist book a demo

    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?