7 Ways to Strike Balance Between Technical Debt and Security Posture in The World of Open Source

Software development at the speed of business is a constant balance of tradeoffs, and managing the risk of open-source software is one of the most emerging prominent examples. This is driven home by high-profile supply chain attacks such as the ones on SolarWinds, Log4J, and MoveIt.

Each of these examples represents a different type of abuse, including:

• Compromise of a trusted third-party organization
• Abuse of popular open-source software
• Abuse of a trusted third-party software product

However, when we start talking about the software itself and how it may be abused, the one stark fact is that open-source software components represent the bulk of contemporary software products. Synopsys’ 2023 Open Source Security and Risk Analysis Report found that 96% of code bases contained open source and that 76% of the code scanned was open source. Not addressing vulnerabilities in the open source in your products could mean that you are only addressing 25% of the attack surface available in your product.

How companies manage these open-source components is instrumental in protecting your product, company, and customers. Software development will always be about making tradeoffs or shortcuts to deliver the product your customers need before they realize they need it. However, shortcuts result in technical debt in the forms of cost, maintenance, and security. It is crucial to balance the technical debt associated with using free and open-source software (FOSS).

Managing Open-Source Risk

There are some steps organizations can take to help manage open source risk.

1. Approval, Approval, Approval. Identify the open source earlier on and begin the process of requesting approval. If modification or new libraries are introduced in existing code, it’s critical to review the FOSS and get approval from your open source and licensing team. Remember, if a FOSS component is approved for one case, that does not mean it is for all cases. This will also bring down technical debt for future FOSS compliance activities. If you do not have an open source and licensing team you need to create one.
2. Maintain documentation of all approvals and exceptions. Dependency tools can discover all the packages and licenses associated with the open-source code. It’s advisable to maintain a proper account of used libraries and its approval from your FOSS committee. Executive Order 14028 specifically calls out the need for a Software Bill of Materials (SBOM) to define a formal inventory of open-source software for organizations wanting to sell software to the United States Government. This basic practice provides transparency and reduces the time it takes to fix issues.
3. Scan and detect open-source vulnerabilities early in the stage. Using IDE plug-ins, which scan open-source packages, can reduce the scope of vulnerability remediation later in SDLC lifecycle. The cost of remediating an issue later in the software development lifecycle is far higher than discovering and implementing alternatives during development.
4. Get ahead of the game.
   • Pick higher-quality component versions and trusted software libraries. Before choosing open source, check its commit history and community. As a rule of thumb, perform your own due diligence while going forward with certain open source.
   • Review your permitted FOSS components and licenses. Has this component been approved for use?
   • Understand where a component is in its lifecycle. Is it actively being maintained? Does the package have any vulnerability database such as the Synk Vulnerability Database.
   • Updating to the latest version may not be the best option. Always try to be on the version which is optimal and has no severe issues. Use tools like Snyk Advisor to get more confidence on any component.
5. Update frequently. Frequent updates may end up consuming developers’ time through maintenance and testing. It’s advisable to stay within an optimal range, move to safe versions, and stay within that group as long as possible, which will result in major cost savings. Teams can reduce risk, save time, and save money by merely being close to the edge. It therefore makes sense to choose software that is an average of 2.7 versions behind the latest.[1]
6. Test compatibility of new upgrades. Always test new upgrades with product functionality. The last thing you want is a product breaking due to certain new libraries or packages.
7. Virtual patching. When certain zero-day exploits are discovered, think about how you can mitigate by other means. An example is to develop custom WAF rules to detect web application related attacks.

Figure 1: Source: Sonatype 8th Annual State of the Software Supply Chain Report

But What About Out-of-Date Libraries?  

There can be situations when the library is not actively maintained and is insecure but is deeply rooted in the product. In this situation, it is still necessary to find a balance.

1. Reach out to the author. Sometimes the author may just be willing to share in the maintenance effort. Reach out to the author and see how you can help, and also discuss with your internal team and FOSS committee if your organization would like to take up the maintenance if the package is a crucial part of overall product, functionality,
2. Try an alternative package. Try finding an alternate package that provides similar functionality. Switching libraries, however, may not be simple depending on how it’s used in the code. Discuss this option with peers, an application security team member, and your FOSS Committee.
3. Source the library internally. If the library is heavily used in the organization, reach out to different teams and explore opportunities to clone and maintain the library internally.
4. Code it yourself. If libraries are out of date, insecure, and not maintained, try coding essential features yourself. This is not always the best choice, as it will take substantial development effort, but it also reduces risk to open-source exposure.

Discover, Approve, Scan, Review, Repeat. Choosing the correct open source is difficult and not addressing can incur a lot of technical debt.  It is necessary to use your best judgement.

Karan Goenka | Application Security Lead
Karan has extensive experience leading technical teams and delivering enterprise-wide technology for cybersecurity transformation programs like cloud and application security architecture, cyber risk, compliance, governance and security strategy.

Michael Fischer | Sr. Director Information Security
Life-long student, hacker, and learner that arrived in security after a lengthy stint as a software engineer in multiple industries.