Over a million developers have joined DZone.

Reactive Maturity Level for Open Source Security and License Compliance

DZone's Guide to

Reactive Maturity Level for Open Source Security and License Compliance

In today's post, we are going to talk about concerns and motivations of Security and License compliance at the Reactive level.

· Security Zone ·
Free Resource

Discover how to provide active runtime protection for your web applications from known and unknown vulnerabilities including Remote Code Execution Attacks.

Technology is constantly transforming how your organization is run for the better. You empower stakeholders to make smarter, data-driven decisions; shape customer interaction; ensure business stability and security. But, when an average application has more than 50% of its code based on open source, 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 homegrown 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 to have a discussion on governance, risk, and control maturity with your team!

Find out how Waratek’s award-winning application security platform can improve the security of your new and legacy applications and platforms with no false positives, code changes or slowing your application.

security ,software composition analysis ,cybersecurity ,reactive level security ,open source security

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}