As threats increase, the time has come to put a full-blown structure in place that turns reactive steps into a proactive protection strategy on OSS.

The use of Open Source Software (OSS) is on the rise, with more than 95 per cent of applications today using it. There are many advantages to OSS, but it’s also fair to say that security and vulnerability risks have gone up. The highest number of vulnerabilities to date were reported In 2017, increasing 14 per cent to 19,954, up from 17,147 in 2016, according to the Vulnerability Review 2018 – Global Trends, the annual report from Secunia Research at Flexera.

Difficult to know true OSS use

One of the biggest challenges for a company is knowing what OSS code is in place.  Code could have been grabbed by the development team for a fast solution, hidden in third-party software, or even brought in through an employee purchase of an application (called Shadow IT). The reality is that few organisations can say with certainty that they know what’s in their code and where it’s being used.

The need for a process to manage the risk of vulnerabilities has never been more important.  Most IT and security teams have taken steps to minimise the risk.  But as threats increase, the time has come to put a full-blown structure in place that turns reactive steps into a proactive protection strategy.
Assess readiness, OSS maturity framework

To create a better process, it’s important to assess where things stand today. Using a formal framework offers a specific method to rate the maturity of a program and guide the next steps to strengthen protection.  Levels can range from “reactive” to “enabled/automated” to “optimised,” with each bringing deeper protection strengths.

An assessment should include 3 key components:

– Vulnerability management—preventing security defects due to third-party component usage
– License management—managing open source license compliance and reducing the Obligation management—discovering commitments related to the use of OSS, based on associated licenses and company policies
– Component management—creating insight into how or what components are used to influence usage and product roadmap decisions

By examining what type of processes and structure are in place for these areas, a maturity ratings level can be assigned.

Identify your maturity level and actions needed

Whether a company is just getting started with OSS policy or has basic automation in place, assigning a maturity level helps IT and security team articulate where the company stands and its needs going forward.

Level 1: Reactive

It’s clear that OSS use is growing.  The need for a process and automation is emerging, but no infrastructure exists to assess and act on the risk.

Characteristics of a reactive level team include using a homegrown tool for certain high risk applications or simply asking developers to identify the OSS used for key projects. Signs are appearing that a formal team should be considered to determine and implement policy. There is little process or automation in place to monitor OSS components or uncover vulnerabilities.

To move to the next level, the best starting point is educating the company on the risks and the benefits of a repeatable, automated process.  It’s time to create a team of people responsible for managing OSS use.  There may be concerns about a program slowing down getting product out the door, so it’s also important to discuss how technology streamlines the structure.

Level 2: Enabled

The beginnings of a formal process are in place.  Awareness of the need has increased and initial metrics for security and compliance exist.

Companies at this level likely scan some applications with a commercial code scan tool for vulnerable code once or more before product launch.  Developers are asked to identify OSS use and a bill-of-materials can be created but it’s not complete.  OSS risk is considered in project plans but there’s no consistent evaluation of risk.  The IT and security teams can perform limited scans and some vulnerabilities can be remediated if an incident occurs.

The next level can be achieved by documenting processes and controls that create consistency for engineering actions and priorities.  Processes should be automated to avoid delays in shipping products.  Greater governance automation’s put in place and management begins to receive regular reports on OSS risk.

Level 3: Automated

Organisations use automation for high-level scanning of applications, but also deep scanning for “hidden” uses.  The development process includes OSS monitoring. When product updates need to be released, there’s no rush for security-related patches. Remediation of issues and component selection becomes easy.

Automation brings value for companies at this level through the use of a commercial scan platform to scan code early in the software development lifecycle. Automated, high-level scans automatically occur across the board, but it’s become apparent that package level analysis may not be enough. Tools are being explored to uncover more visibility into dependencies, subcomponents and commercial code without significantly increasing people and cost. Continuous monitoring occurs, and a formal open source review board manages and educates on policy. Engineering teams easily prioritise reported issues and respond quickly to alerts. A strong communications plan kicks into gear for identified vulnerabilities and the team is equipped to remediate vulnerabilities, although limited by the depth of scans.

Achieving the next level focuses on two areas: consistency and adding deep level scans. Through documentation, processes and controls, emphasis should be on reinforcing engineering actions to continuously monitor, prioritise and remediate issues.  It’s also time for deeper level scans, including code from suppliers and partners.  A system should be set up to ship products with third-party disclosures.

Level 4: Optimised

The optimal level of protection and management includes a powerful combination of infrastructure, automation and education. The company operates with the understanding that some projects have more risk exposure than others and must receive a deeper analysis. Partners and suppliers are now part of the process with strong checks and balances for security and compliance.

Success at the optimised level means the protection’s in place to empower rapid and safe adoption of OSS.  Visibility exists as well as a consistent feedback loop on any exposure. Monitoring’s automated at a high level and at a breadth & depth that protects the company from “hidden” vulnerabilities. That visibility extends to code received from partners or vendors.  The security and IT teams now have enterprise-wide planning insights to build a proactive, robust protection strategy.

While most companies may not perfectly fit into a maturity level, using a framework offers a way to set a baseline of current infrastructure and defining the best next steps to strengthen OSS vulnerability prevention.  It’s a great way to answer—are we ready?