Revenera logo
Image: Enabled Maturity Level for OSS and License Compliance

In a previous blog post, we introduced you to the Software Composition Analysis (SCA) maturity levels and walked you through the need for best practices around SCA. Today, let’s talk about concerns and motivations of security and open source software license compliance at the enabled level.

Enabled Level Security and License Compliance

The big difference between the Reactive and Enabled maturity levels is improved risk assessment around open source use. And short term success metrics for security and compliance. Teams at this stage have made progress in all four dimensions of SCA business objectives.

  • Vulnerability management: Improved analytics and process – You are beginning to see better component selection due to vulnerability insights. Your team is trained on corporate vulnerability policy, and is able to make go/no go decisions at less cost to the enterprise.
  • License management: Reduced risk due to undisclosed OSS/third party component use. You are seeing cost savings from automation of component selection processes & self-service based on automated and defined policies.
  • Obligation management:  Improved customer satisfaction by lower vulnerability exposure. Improved customer satisfaction with insight into legal obligations. Reduced legal risk from unfulfilled legal obligations.
  • Component management: Security/Legal risk analysis is informed by component usage. Rapid response to zero day and other high importance vulnerability alerts across the enterprise.

Current State for an Enabled SCA team – Process is Formalized and Repeatable

  • Tooling:  You likely scan your applications with a commercial code scan tool for vulnerable code one or more times before shipping. Some companies put the onus on the developer to disclose their use of OSS in some projects instead. You are able to consistently create BOMs with your products, but these are incomplete. Most of your scan and analysis is limited to high level software packages.
  • Teams and training: Your ad hoc open source management team has policies and enabled training around Open Source security and compliance. Enabled teams are focused on creating and consistently evaluating open source security and compliance initiatives.
  • Monitoring OSS: This is the area of most improvement. OSS Risk is considered in project plans and initiatives. You able to determine when a new vulnerability affects you in the high level packages you are being tracked and monitored.
  • Incident management: At this stage, you are equipped to re mediate some vulnerabilities and are beginning to formulate an action plan if an incident occurs.

Motivations for an Enabled Level Team

Enabled level teams have process and controls in place but they are not well documented. Engineering actions to remediate issues are not prioritized or consistent.

While it is a repeatable process, it is not automated. This may causes delays in shipping products on time. There is limited visibility into component / version use information. Legal teams want more governance automation and policies to reduce burden on their team. These is also a push to Continuously track and report on OSS risk to management.

What Maturity Level is Adequate to be Secure and Compliant?

Depends on your objectives. The SCA maturity model allows you to benchmark your process into levels, instead of defining a pass/fail, hard to achieve metric. A defined, repeatable process with a clear goal of continuous improvement should be the aspiration.

Use this framework and guide for discussion of governance, risk, and control maturity with your team.