The harsh reality of managing software supply chain risk is that software teams cannot remediate hundreds of issues in one big bang project to improve the software’s risk posture. The aggressive release cycles software teams are facing and the complex nature of today's applications only add to the problem. With 87% of surveyed software professionals saying their companies detected software supply chain issues in the last 12 months, it’s clear that some rethinking of how to prioritize remediation tasks has to happen.
In our experience, initial scans with comprehensive software supply chain risk reporting can be shocking, especially for teams with minimal or “checkbox” application security programs. Seeing a list with hundreds of high priority issues evokes immediate denial:
• “All of those must be false positives”
• “There are no old versions of that OSS library in our software”
• “We’ve already released that software so there can’t be malware in it” -
While there is an element of graveyard humor in these denials, it underscores the harsh reality of balancing the need to improve software’s risk posture and the development team’s capacity to remediate. These monster remediation efforts must be tackled in a way that developers understand – a continuous improvement approach, with feature roadmaps, project sprints, backlogs, etc..
Continuous Improvement Approach for Software Risk Remediation
But there is a catch, it’s not always obvious which subset of an application’s high priority issues to focus on before shipping an up-coming release, and then decide what to tackle before the next release, and the next one and the next one. Then there is the effort needed to automate those decisions as security gate policies and documenting that the issues remain remediated with every subsequent release. As a result, there are several moving parts and new threat analysis skills required to make a continuous, step-by-step improvement approach actually work in automated software build and delivery environments.
Making remediation accessible to developers with continuous improvement work is the focus of our new capabilities. Application security and development teams get a clear path for “leveling up” their supply chain security with predefined groups of policies (which we call ReversingLabs Levels) which:
1. Simplify the creation and application of meaningful milestones for improving software supply chain security
2. Reduce remediation alert noise as the development teams work to satisfy the criteria for the Level applied to their software project
3. Continuously assess how far the software is from achieving each Level and while retaining comprehensive visibility into the software’s current risk posture
Remediation roadmaps made easy
Designing a continuous improvement approach can seem a daunting challenge. Not all organizations and teams have the capacity or expertise to decide the requirements for each improvement milestone, manually review dozens of pass/fail policy settings, implement policies as CI/CD security controls and devise reporting to demonstrate improvement while indicating future remediation plans.
ReversingLabs solves the security skills and resources challenge with predefined policy groups that help teams gradually improve their software security. There are five Levels, each designed to be a milestone for increasing software supply chain security (see Fig). Simply apply Levels to a software project and a 5-step security controls roadmap & overview reporting is automatically created for you. When a scan indicates all criteria for a specific Level is met, the software receives the PASS status for that Level.
ReversingLabs Software Supply Chain Security Feature: Levels
The first level is designed with a “last line of defense” mindset, which is where many of our new customers start. The primary concerns are:
• Preventing release packages or containers with malware or signature tampering from reaching production environments
• Plugging any leaks of source code or unprotected keys that can put the business at risk
Levels build up on each other, so every step up implicitly requires the criteria from all previous levels. This enables application security teams to quickly get started and demonstrate a clear improvement path going forward. Tailoring policy settings for a specific Level also becomes a more manageable task, enabling organizations to customize based on specific use cases, compliance requirements, or third-party or legacy components in the software.
Developers get clear guidance on what to fix and ensure several types of supply chain risk are addressed at each level. This is important because most development teams only understand being blamed for source code vulnerabilities. That antagonistic behavior perpetuates the denials discussed earlier – even in the face of actual breaches. These folks need time, coaching and some “quick wins” to adjust to the new reality where application scanning is their defense against malicious actors backed by nation-states with millions to spend on attacking software supply chains.
Turn down the noise to improve results
The longer the to-do list the less motivated anyone is to tackle it. This is true whether it is responding to emails after being on vacation, a home improvement project, or supply chain security remediation.
Security remediation fatigue experienced by developers
As we showed with our Secrets feature release - using additional context to prioritize helps development teams focus on what they can fix. In this case, the additional context is the specific Levels applied to the software.
For example, before Level 3 is applied as the security control, the software team would be inundated with 287 high priority remediation alerts. With Level 3 applied, this number drops to 22 – because the platform is automatically suppressing the alerts from other high priority issues until the team is ready to take on the next level up. This also helps build a culture of continuous supply chain security improvement which is fundamental to successful DevSecOps adoption.
The yellow PØ indicator and the “L3 Pass” in the CI/CD column indicate that we are aware of the risks but we will fix them in a later project on our roadmap. Thus, security and risk management teams retain comprehensive visibility into the software’s current risk posture, while developers can focus on achieving their current goals.
With less noise, developers can focus an achievable to-do list
Reporting that simplifies the path
The last piece of the puzzle is reporting that makes it easy to know where you are and see the path ahead and provide data showing that remediation progress is being made. Dropdowns from each level clearly state the requirements, and the links between each Level indicate how far you are from achieving the next level. Also, if you’re thinking about using a new library in your code – a scan of the library will indicate whether that addition will knock you down a level or add a lot of extra work to achieve the next level up.
Every scan attests to efficacy of your continuous improvement efforts
Benefits of a continuous improvement approach
ReversingLabs Software Supply Chain Security enables you to implement a continuous improvement approach to managing software supply chain risk that is:
• Less disruptive
Organizations can start improving software supply chain security in smaller increments which are less disruptive to development teams
• More effective
Supply chain security risk is managed without overhauling existing processes or implementing complex frameworks
• More sustainable
Automated reporting demonstrates both early wins and attests to continuous improvement, which is necessary to build a culture of security awareness and shared responsibility
With ReversingLabs, development and application security teams can take the toil out of identifying, prioritizing and remediating software supply chain risks for their organizations.
Free Trial – Experience how Levels can work for your teams
