Reactive Maturity Level for Open Source Security and License Compliance

Today’s technology professionals are transforming how your organization is run. You empower stakeholders to make smarter, data driven decisions, shape customer interaction and ensure business stability and security. When an average application has more than 50% of Open Source code, OSS is a business lever you must manage well.

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 more about  concerns and motivations of Security and License compliance at the Reactive level.

Reactive level Security and License compliance

Reactive level teams are beginning to understand that their use of Open Source Software is skyrocketing. Management realizes the need for process and tooling to manage these open source assets, but there is very limited risk assessment or success metrics.  Security teams at this level understand that the four dimensions of SCA are their primary business objectives.

  • Vulnerability management: Realization that vulnerability management is needed to prevent security defects due to third party component usage.
  • License management: Recognition that manually managing open source license dependencies impacts legal risk.
  • Obligation management:  Understand manual obligation management is costly, inconvenient and incomplete.
  • Component management: Security/Legal decisions made with little or no insight into how or what components are used.

Current State for a Reactive SCA team – Expectations are identified or tracked informally.

  • Tooling:  In some cases, your team uses a home grown tool for certain high risk applications to detect high level software packages. More commonly,  teams may ask developers to disclose the OSS they use in some projects. A bill of material is only created in response to a customer request, usually by visually identifying high level packages in the application code.
  • Team: Reactive teams are beginning to understand the need for a formal or ad hoc team to determine and implement corporate policy around Open Source.
  • Monitoring OSS: Are you able to determine when a new vulnerability affects you? Not at  this stage. Your team is not enabled to monitor Open Source components or associated vulnerabilities.
  • Incident management: Incident Management can be seen as the true test of SCA maturity – Are companies able to react to major security and compliance issues in time? At this maturity level, your teams are not equipped to remediate vulnerabilities.

Motivations for a Reactive level team

In the current environment, Reputation Management is the top concern at all levels of SCA maturity. Reactive Legal and security teams are leading the charge for your applications to be secure and compliant. With the WannaCry and Equifax hacks still looming heavy over software organizations, there is a big push to understand and manage software vulnerabilities in commercial software and software developed for internal use.
Engineering teams are in agreement. Most engineering managers at this maturity level are educating themselves on a repeatable, automated process, and the need for a team of people responsible for creating and managing this process. They realize this is necessary, but there is the perception that a security tool will slow down production.

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. Follow this space for a discussion on the next level of Software Composition Analysis next week! If this sounds like you, let us know your primary concerns  in the comments.

Leave a Reply

Your email address will not be published. Required fields are marked *