Eighty percent or more of the code used in modern applications is open source, making it a part of our critical infrastructure. However, nearly 95% of application vulnerabilities result from open source code packages indirectly pulled into development projects without developers' approval or knowledge, according to recent Endor Labs research.
Given the staggering risks lurking in open source code, as well as the enduring reliance on open source software (OSS), there is a growing call for regulations to detect and excise malicious code before it reaches users. On March 29, the Senate Committee on Homeland and Government Affairs voted to pass the Securing Open Source Software Act, which is the first legislation to propose regulations on OSS. While the legislation is a positive step towards securing OSS, the bill is vague about the measures it will take to implement recommendations and even less clear on how it will enforce regulations.
One tenet of the bill recommends that the Cybersecurity and Infrastructure Security Agency perform an annual audit on all OSS used by government agencies. However, this will depend on the agencies’ cooperation, which remains to be seen.
Four Key Areas for Open Source Software Security Programs
To successfully roll out regulations, industries will need clear benchmarks for implementation, according to Endor Labs CEO Varun Badhwar.
Badhwar said the first and most important step in mitigating OSS security risks is to identify and understand which risks pose the greatest threats. Endor Labs recently released a report on the top 10 OSS security risks.
He highlighted four areas that organizations must consider when implementing an OSS security program:
- Selection criteria: Organizations must assess how they help developers select safe, sustainable open source dependencies. They must also enforce dynamic and automated governance policies that match the organization’s risk tolerance and consider selection criteria like Popularity, Trustworthiness, Quality, and Security. These policies should be non-intrusive and fit developer workflow, ideally right in the IDE as packages get pulled in.
- Risk prioritization: Once code is in motion, vulnerabilities are inevitable. Organizations must have a way to prioritize security and operational risk that can affect the business. This would typically mean going beyond risk severity and analyzing reachability at the function level.
- Ongoing maintenance: In most organizations, OSS use is a tangled web. Updates can have a negative domino effect if not planned properly. As such, organizations need visibility into how code is used so they can determine the impact of code updates. Organizations must also work to eliminate duplicate versions and unused, unmaintained, or unsupported dependencies.
- Compliance with emerging standards: The increased scrutiny on open source usage through the White House Executive Order, National Cybersecurity Strategy, and the Securing OSS Act means that organizations must prepare to produce accurate software bills of materials and accompanying VEX (Vulnerability Exploitability eXchange) documents.
What Are the Weaknesses of Current Risk Detection Practices?
Until now, software composition analysis (SCA) tools were the go-to method for detecting and measuring risk in software development. However, even the latest SCA tools focus on only two challenges: license and vulnerability compliance.
Vulnerability management poses additional problems to productivity because of a lack of context around which vulnerabilities matter most. As a result, developers often waste time patching components that don’t affect the application.
SCA tools suffer from three shortcomings, Badhwar said:
- They do not help developers select secure and high-quality dependencies. Without this, organizations quickly stack up technical and security debt, which is hard to address later.
- They only track a single and lagging risk vector – known vulnerabilities. Known vulnerabilities are typically bugs in well-meaning developers’ code and neglect multiple categories of attacks from malicious developers.
- They often lack context into transitive dependencies (where 95% of vulnerabilities are) and into how code is used. Typically, SCA tools will filter security alerts based on severity, resulting in developers chasing a vulnerability because of its critical status, despite it not actually being a threat because it’s unreachable or in test scope.
These weaknesses help to explain instances like the "Review of the December 2021 Log4j Event" report released by the Department of Homeland Security’s Cyber Safety Review Board. That report, which notes that at least one government agency spent 33,000 hours responding to the log4j vulnerability, illustrates that teams can’t easily identify where the errant software exists within the environment.
How Do Organizations Improve Risk Detection Ahead of Future Regulation?
Organizations can assess their open source software, identify vulnerabilities, and highlight which threats require immediate attention, Badhwar said. Using updated program analysis and dependency lifecycle management technology can offer insight into how organizations use code and flag any dangerous vulnerabilities.
Dependency management can also help organizations create detailed dependency graphs without requiring any agents or proxies in runtime. Implementation can become easier while allowing organizations to quickly understand how developers use dependencies. “This means that the next time an organization faces a Log4j-like incident, it can find the problem in minutes rather than weeks,” Badhwar explained. “This is the only realistic way to secure the reliance on open source at scale.”
