In previous posts, we discussed the Software Composition Analysis (SCA) maturity model and walked you through the first two levels of maturity – Reactive and Enabled. In this post, lets walk through the Automated level of SCA maturity.
So, what does Open Source Security and Compliance mean at the Automated level?
The objective of SCA teams at this level is Integration and Automation across all four dimensions of SCA. This makes vulnerability remediation and component selection transparent and easy for developers. Product teams can release rapid, controlled product updates and reduce maintenance revenue leakage by eliminating rushed security related patches.
- Vulnerability Management: At this level, Process Automation is the primary business objective. To make this happen, OSS security is made a part of your continuous build process. Teams continuously monitor code via alerts – this allows engineering teams to remediate code faster and more often – with the final goal of reduced customer exposure to security risks.
- License Management: An automated team sees better developer experience – this comes from automating the license management process using policies. At this level, Out-of-compliance applications are minimized across the organization with prioritized effort from the engineering teams.
- Obligation Management: The automated team also improves legal and security compliance through obligation automation – especially by automating Third Party Notices. You reduce the cost of providing current version to version compliance artifacts.
- Component Management: An important business objective at this level is to include data driven component use insights in making roadmap decisions. This allows your team to reduce usage of low count or low quality components in lieu of vetted corporate standards.
Current State for an Automated level team – Security scans are integrated into your software development lifecycle
- Tooling: At this level, you are using a commercial scan platform to scan your code early in the software development lifecycle for License and Security issues. Your teams have automated high levels scans across the board, but realize that package level analysis may not be enough. You are experimenting with tools to get more visibility into dependencies, subcomponents and commercial code without significantly increasing people and cost.
- Team: An automated organization has a formal open source review board that is responsible to set and update corporate policy. This team trains and enables developers to use open source while understanding risk. they continue to analyze and report on OSS usage.
- Monitoring OSS: Continuous monitoring is key at this level. An automated team can easily determine when a new vulnerability affects your organization in the code being tracked and monitored. Process and policy is much better understood and implemented at this level. This allows engineering teams to prioritize reported issues and respond quickly to alerts.
- You have a good Incident Management and communication plan if a new vulnerability is discovered. Your team is equipped to remediate vulnerabilities in your applications, though you are limited by the depth of scans.
Automated level teams have well documented process and controls in place, and are enabled to understand the usage and risks of Open Source. All your products ship with Third party disclosures. Engineering actions to continuously monitor, prioritize and re mediate issues are consistent.
Motivations for an Automated SCA Team
Some of your applications carry more security risk than others. How do you channel effort to the high risk projects?
You team is also beginning to understand that much of your code comes from suppliers and partners. This code is integrated into your own and carries the same amount of risk.
Look out for our next post to understand the final Optimized level of maturity, and how they manage these concerns.