Tracing Software Lineage To Avoid Open Source Vulnerability
Here’s how tracing software lineage can help pinpoint vulnerabilities.
Often in the case of the software supply chain, it’s hard for software producers and consumers to pinpoint where problems like vulnerabilities exist. Monish Advani, head of product at Lineaje, discusses how tracing software lineage can help provide more visibility into threats and vulnerabilities.
A software supply chain is similar to a vehicle assembly line. Each part of a Tesla, such as a seat or a door panel, most likely came from a different manufacturer. By comparison, a software supply chain is made up of many components that have been sourced from software built internally or by third parties. So, what happens when there is a problem with the passenger seat? How does Tesla address the issue? Chances are Tesla knows exactly which manufacturer to contact to fix the seat across all of its vehicles, but in the case of the software supply chain, customers do not know where the problem exists.
This is where software is dramatically and sometimes tragically different. In many cases, organizations don’t have visibility into the code’s origin, DNA, or authors, especially when software is built on open source or third-party code. That lack of insight can be catastrophic and widespread in the case of an incident.
Open source or third-party code is commonly used in software development today – primarily due to its efficiency. In order to decrease cost and accelerate development, many coders take advantage of pre-existing and readily available frameworks and libraries rather than writing custom code. Yet, this approach comes with its own set of drawbacks and risks, with the contents of that software being unknown. With approximately 80% of application code being open source, ensuring software supply chain integrity has never been more difficult to attain nor more important than it is right now.
High-profile Attacks Increase Security Awareness
Research shows that approximately 95% of open source vulnerabilities are found in open source code packages that are not selected by software developers but are indirectly pulled into projects, making it difficult for organizations to validate how secure the code is from the start. With the rise in vulnerabilities, it’s inevitable that the industry is being stagnated by the attacks that have ensued as a result.
Last year, headlines were dominated by the Apache Log4J vulnerability, a widespread software supply chain weakness that allowed attackers to log a special string of code, exploit their target and install malware or conduct various cyberattacks from there. With Log4J’s widespread deployment across consumer and enterprise systems, network compromise and theft of confidential information was feared around the globe. Furthermore, the lack of visibility into dependencies made the vulnerability more difficult to patch and accurately gauge its severity.
As of April 2022, four months after the vulnerability was exposed, it was believed that over 68,000 publicly accessible systems were still at risk, which begs the question: Do the owners of those systems even have a clue that the vulnerable code exists within their organization? Unfortunately, the only way they might find out is when they are exploited.
Throughout 2022, larger companies like Okta and Uber fell victim to supply chain incidents as well, showing that even big names with deep pockets and sophisticated IT and security departments are vulnerable. According to IBM, the average cost of a breach increased $4.24 million in 2021 to $4.35 million in 2022. Not only are these incidents monetarily costly, but they also affect brand perception and customer trust.
As a result of these well-publicized attacks, there is an increased awareness of the dangers associated with using open source or third-party software. These incidents serve as a grim reminder of the importance of driving efforts and innovation to secure the software supply chain and the potential devastation that can result from an attack.
See More: 5 Steps for Proactively Managing Open Source Software
The Evolution of the SBOM
In May 2021, President Biden issued Executive Order 14028 “Improving the Nation’s Cybersecurity,” noting that “the trust we place in our digital infrastructure should be proportional to how trustworthy and transparent that infrastructure is, and to the consequences we will incur if that trust is misplaced.” An initial step towards the Executive Order’s goal of “enhancing software supply chain security” is transparency.
Much like a list of ingredients on food labels, an SBOM advances transparency in the software supply chain by disclosing what is in the software. The assumption with an SBOM is that if an organization has a detailed list of software components, they can assess risk more accurately. When a vulnerability is identified, the organization can quickly identify and confirm if a risk exists and mitigate damage before it’s too late.
According to Gartner, by 2025, 60% of organizations building or procuring critical infrastructure software will mandate and standardize SBOMs in their software engineering practice – up about 20% compared to 2022. However, protecting the software supply chain doesn’t stop at simply having an SBOM. To preserve software supply chain integrity, organizations must also ensure the accuracy of the SBOM.
Once an accurate and complete SBOM is in place, the SBOM must be managed, maintained and updated with correct information about the software components, which is an added layer of complexity. Beyond simply meeting the SBOM requirement is having the ability to evaluate and assess the SBOM, set security policies, detect potential attacks, and prioritize them before they happen.
How to Avoid Falling Victim
The best way to avoid falling victim to an attack is to acknowledge that a software supply chain problem most likely exists. Not only is the problem prevalent and widespread, but it is also escalating and growing in complexity. The first step is to understand the level of visibility of an organization’s software supply chain in terms of what are the components, who made them and how it was built. Second, the organization must examine the integrity and hygiene of the software to determine if bad code exists and how it can be eliminated. The last step is remediation to find out if there is anything that can be done to fix faulty code. The end goal is to have a clean software supply chain that can’t be tampered with or attacked.
While high-profile security incidents have certainly increased awareness, there is much more to be done to educate businesses on the risks and how to avoid them. The fact of the matter is that the common and widespread practice of using open source and third-party software makes software dependencies and vulnerabilities nearly unavoidable. It’s painfully obvious that there is a supply chain problem, so businesses must start looking inward and examining their software inventory and lineage to uncover potential risks and get ahead of them to avoid costly damages and maintain customer trust.
How do you think tracing software lineage could improve vulnerability management? Share with us on Facebook, Twitter, and LinkedIn.
Image Source: Shutterstock
MORE ON OPEN SOURCE
