Managing Open Source Code With Secure Software Development Framework

Open source software offers many benefits but can also be an attack vector for hackers. Here, Alex Rybak, Director of Product Management at Revenera, details how a secure software development framework supporting governance, compliance, export controls, and safety can squash bugs and flaws through continuous scanning. At the heart of the framework is a comprehensive software bill of materials.

Containers, packages, dependencies, copy/pasted source code snippets, commercial files, multimedia files—all are potential entry points for open source software and other third-party content to enter your proprietary codebase. In short — software is extremely complex. Approximately 80% of codebases are comprised of open source. The increasing use of open source software opens up the possibilities of vulnerabilities and exploits and heightens the need to control and manage impact—both positive and negative.

Whether software is used in an IoT device, a medical device, automotive or aeronautic programs, or in other industries, software vendors must ensure that their products are as secure as possible. 2021 State of Open Source License ComplianceOpens a new window  research report, one out of eight license compliance issues uncovered by an audit are considered Priority 1 (P1), meaning they pose a critical threat that demands a culture focused on license compliance, intellectual property (IP) protection, and best-in-class open source software management. Often less than 10% of the issues uncovered during the audit process are disclosed prior to the start of an audit. This major gap of awareness must be closed.

A secure software development framework, detailed below, supports governance, compliance, export controls, safety, cost management and more. With continuous monitoring, it facilitates an effective strategy to track usage and remediate vulnerabilities. At the heart of the framework is an accurate, complete, and up-to-date software bill of materials (SBOM), which identifies and details all software ingredients, including open source and third-party components used in your applications. 

Today, as more customers are demanding disclosure regarding software components and code security, and with increased awareness of the importance of secure code all along the software supply chain, maintaining an SBOM is essential. Beyond just identifying items with known vulnerabilities, an SBOM is a comprehensive inventory of all components. Something that may not be vulnerable today may become problematic tomorrow; monitoring all components allows you to fix and patch appropriately when a vulnerability is found—and to ensure that you’re not putting your customers at risk.

Learn More: Who’s Responsible for Data Protection in the WFH Era – IT or DevOps?

When and Where to Scan

A secure software development framework identifies and records all open source software components in use, as conducted through the process of Software Composition Analysis (SCA). There’s no single, ideal time in the development process to scan your codebase. Instead, it needs to happen continuously. Starting as early as possible in the process—an expand-left approach—can address security and compliance issues before they grow more complex and more costly to remediate. (Remember: the longer you wait in the release cycle to fix an issue, the more expensive overall). 

Continuing right up until you’re ready to release a product is equally important to ensure that your SBOM is complete and accurate. Given the complexity of today’s products, not everything can be 100% automated. The human element still matters, as do common sense reviews. After all, automations are only as good as the policies that you create.

Where should this continuous scanning activity take place? Evaluate each of the following.

• • Artifact repository: An artifact repository’s goal is to provide a trusted source that doesn’t need a lot of manual attention, thereby increasing confidence downstream. Artifacts available via your artifact repository should have gone through a vetting process (legal, security, etc.) and have been approved for use. With defined and allowed usages within your organization, your engineering team knows it can use these artifacts as a way of mitigating riskOpens a new window . Continue to monitor this artifact repository for new components (artifacts) and newly reported security vulnerabilities. An automated, ongoing scanning process can flag new items and items that violate your corporate policies. Items not matching existing policies should be manually reviewed and the corporate policy adjusted for future automation.
  • Integrated development environment (IDE): Conducting local scanning on a developer’s laptop—as that individual is writing code and before checking in any changes—is an important step. Think of this as a smoke test—an opportunity to preview any policy violations and to fix issues as far to the left in the development process as possible. Once a non-compliant file is checked in, a remediation cycle will be required to fix it; you might as well catch it and fix it prior to check in, where possible.
  • Builds: SCA needs to be part of the build ecosystem. As long as it’s automated, scanning can be done as part of a continuous build integration, nightly, or through release team builds. Assess compliance per your organizations’ policies. Have a process in place to understand and address exposures discovered in the build. In some cases, set up a release gate or compliance check to automatically fail a build or log a defect in the bug tracking system based on egregious compliance issues.
  • Ecosystem: Monitor your dependencies (database, operating system, and other open source, third-party, or commercial applications) to have full knowledge of your ecosystem, not just your application. Remember things outside of your product, such as the platform or containers, if you’re running a virtualized application.

Scanning throughout a build will do a good job of identifying changes, but conducting periodic system-level deep dives is necessary, too. These are opportunities to look at the entire product, including its dependencies, the code you’ve written, and the third-party code that’s been pulled in. A deep dive is the last gate to ensure that your product is secure when it’s ready to go out the door.

Learn More: How to Fight Damaging Insider Threats With Multi-Layered Security Approach

Benefits to Integrations

Automated scanning through SCA provides multiple benefits, among them:

1. Data currency: Ad hoc, periodic (e.g. quarterly or annual) manual audits don’t satisfy the requirements of many governance programs. Continuous knowledge and scanning are necessary. Whenever there’s a code change, your SBOM needs to be updated, and compliance issues need to be reported. The integration provides identification of issues as early as possible within the software development lifecycle (SDLC); keeps the SBOM updated rather than static; and allows you to do your work in incremental bite-sized pieces, with a continuous approach that’s manageable, not overwhelming.

2. Regulatory compliance: Increasingly, regulations including FDA, GDPR, NTIA, PCI, and others require a continuous process that accomplishes the following key requirements of a governance program:

• • Maintain an up to date Software Bill of Materials (SBOM) including all open source software components used in your applications.
  • Follow a process to identify known security vulnerabilities within open source software components.
  • Monitor existing open source software components for new security vulnerabilities.
  • Maintain a policy and patching process to remediate impacted open source software components.

3. Ease of use: Scanning for open source components is easiest when the process happens automatically, managing by exception, letting the system tell you where there’s work to be done. Set up your policies, criteria, and thresholds, then let the tooling you’ve put in place tell you where human work is required to remain compliant.

Design for Company-Wide Support

For companies that haven’t yet focused on a secure software development framework and those looking to improve their current programs, remember that education is key. Company-wide support is the best way to ensure the success of your goals. While most initiatives will evolve bottom-up in a large organization, support from the top is critical to keep the initiative going and maturing over time. More than just a responsibility of the software developers, this approach requires understanding and buy-in from other stakeholders, including senior leadership, legal, security, compliance, and sales teams, who may get related questions from customers. Educating team members about policies is the best way to ensure a shared understanding of the program’s goals.

The earlier you include stakeholders, the better. Remember that processes fail when rules are imposed on engineers without them understanding the significance of a particular assignment as part of their jobs as developers. Rather than imposing how a secure software development framework will be implemented, guide the team about what the outcomes must be. Design a collaborative process that will be adopted, not resisted.

Let us know if you liked this article or tell us on LinkedInOpens a new window , TwitterOpens a new window , or FacebookOpens a new window . We would love to hear from you!