The phrase “corporate change management” frequently conjures images of CEOs, executives and leadership teams spearheading responses to market fluctuations, industry shifts, technological disruption and unknown forces like the current coronavirus pandemic. Today’s turbulent times require a fresh approach. Modifications to processes organisation-wide can help teams prepare and respond to changing environments, while strengthening an organisation’s position and ability to withstand challenges.
When any of the events above happen, companies can find themselves with reduced or reorganised resources. When resources are limited, automating processes that were previously done manually can become top priority. As companies take cost cutting measures—reducing staff, streamlining teams, tightening their belts on resources—it becomes a good time to strengthen infrastructure, technology and back office systems and processes.
One area where this is particularly relevant is in the management of open source software (OSS), including management of the license compliance and security issues that come with its use. Developers leverage OSS in their proprietary applications to speed up time to market and drive innovation; applications often include up to 80 per cent+ of OSS. However, the OSS knowledge gap continues to increase, with an OSS usage disclosure rate of only 6 per cent of what is actually found in audits. This usage can lead to more security vulnerabilities, exploits and breaches, driving an emphasis on regulations from multiple industry groups. Now is not the time to reduce open source usage or disregard open source risk.
Software Composition Analysis (SCA) is the process of identifying and recording the use of all open source software components in your codebase. Open source software can enter your codebase in many forms including software packages, containers, build dependencies, complete source code files, copy/paste fragments of source code files, binaries, images, documents and multimedia files. SCA helps manage IP risks due to non-compliance with legal obligations, security risks due to vulnerable OSS components and reputation risks. Ignoring or deprioritising SCA due to resource constraints might seem prudent in the short-term, but can lead to incompleteness and inaccuracies in your Software Bill of Materials (SBOM), leading to an increase in the aforementioned risks over time.
The need to respond to corporate changes presents an opportunity to invest in engineering process improvements and technical debt burndown, while mitigating the risk that comes with reliance on OSS components. Limited engineering cycles mean that wasting time on remediation isn’t wise; anything that can help catch issues early and often becomes a critical task to allow engineering to continue to focus on innovation. Integrating SCA into the DevOps process can help companies gear up for higher customer demand when the economy improves and the pace of engineering further increases. Managing open source risk in a changing environment is all about governance and automation, in tandem.
Governance—including oversight and control—of an open source software usage program is more important than ever to protect against malicious attacks in times of disruption or great change. In order to implement any governance program, understanding what’s in your software is essential. A SBOM, created through the SCA process, becomes imperative for any effective governance program. The SBOM provides transparency into the makeup of your software applications and records the sub-components and dependencies, along with associated licenses and security vulnerabilities comprising your applications. The SBOM can help inform your approach to open source policy and help you react to vulnerabilities. Due to the level of complexity in today’s software applications, without a complete and accurate SBOM, achieving and governing a complete, secure open source ecosystem is impossible.
There is no time like the present to establish an open source governance program and integrate it into the development toolchain in order to comply with open source licenses, manage obligations and maintain up-to-date knowledge of relevant security vulnerabilities impacting your application. Rather than performing ad-hoc scans or implementing scanning toward the end of your application development cycle, start earlier in the DevOps lifecycle, with an automated and cost-effective process. This expand-left approach helps manage compliance and security risks early and often, while protecting your intellectual property (IP). On the other hand, an incomplete, delayed or ignored SCA process may lead to costly litigation or last-minute remediation work.
Moving this scanning earlier in the lifecycle—and scanning often—can help streamline the efforts required to meet regulatory standards. For example, SBOMs are essential to meet PCI (payment account data) standards for secure software; the EU’s General Data Protection Regulation (GDPR) requirements for security of processing; the US Food & Drug Administration (FDA) updated cybersecurity recommendations; and the National Telecommunications and Information Administration (NTIA) guidelines for software component transparency. All of these initiatives share the following common requirements to:
- Maintain an up-to-date Software Bill of Materials (SBOM) of all open source software components use 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, and
- Maintain a policy and patching process to remediate impacted open source software components.
The good news is that all of these requirements can be satisfied with continuous SCA. In a nutshell, continuous SCA is an evolution from ad-hoc audits to a manage by exception process. It includes the following key initiatives:
- Integration of SCA into the engineering tool chain (artifact repositories, IDEs, source management systems, CI/CD builds, containers and issue trackers)
- Active monitoring of existing Software Bill of Material items for material changes
- Alerting appropriate users in cases of non-compliant items and new security vulnerabilities
- Initiating remediation and patching of vulnerable code
As staff contracts and internal audit teams are often scaled back during times of turbulence and extreme corporate changes, remaining staff gets burdened with more work. That skeleton crew must prioritise efficiency and productivity in order to get through the workload.
Automation in SCA makes up for lost and often forgotten manual efforts. An automated, standardised and repeatable process can help manage open source license inventory with increased accuracy, even at a time when staffing constraints are particularly tight. However, like all complex processes that require human interpretation, some manual processes will always remain. It is therefore important to factor those into your process and help set the right expectation with your stakeholders.
An automated SCA lifecycle includes:
- Inventory creation: typically done via manual disclosures, automated scanning and, in some cases, manual analysis
- Inventory triage: typically performed by the engineering team as a sanity-check to ensure both accuracy and completeness of the application codebase
- Inventory review: can be performed automatically using pre-configured policy rules which are typically based on component, licensing, component usage and security criteria; or performed manually by various stakeholders to ensure that inventory items comply with corporate license and security policies
- Inventory remediation: typically performed by engineering and generally splits into license obligation fulfilment and application changes to address security vulnerabilities for non-compliant items
- Completion: achieved when inventory items are considered to be done after they’ve been reviewed, remediated and don’t contain any open alerts. Approved inventory items are considered done when all compliance related work has been completed; while rejected inventory items are considered done when all technical debt work is completed.
Automation makes open source management an intrinsic part of an engineering process. First and foremost for staff, it means that no one has to push a button or otherwise remember to start an inventory management process at a particular time. Automated alerts inform users of critical changes to their SBOM items, including IP compliance issues and new security vulnerabilities. Tasks are automatically created and assigned to the appropriate users to track remediation work for non-compliant items.
Data currency is also strengthened through automation. Manual methods, including audits, provide snapshots of a codebase at a particular point in time. While useful, these snapshots become outdated quickly and can result in compliance issues being identified too late into the software development life cycle. Furthermore, the volume of data in a snapshot model is overwhelming, whereas an automated, continuous use approach is more manageable. Since your codebase and the resulting SBOM aren’t static, integrating code scanning into the DevOps environment is a way to ensure that risks are caught and remediated early and often. The cost to remediate a security issue in a released application can be up to 150x that of an issue being identified early in the development process.
Nothing is static. Code isn’t static and neither are the processes related to ensuring its security. The only constant is change. Because risk compounds over time, addressing risk early and implementing an effective program for ongoing monitoring of that risk is critical. Ignoring license compliance or deferring security risk management can be more costly in the long run than actualising an open source governance program from the start.
Alex Rybak, Director of Product Management, Revenera