SSCRM: Going Beyond Application Security
Software Supply Chain Risk Management (SSCRM) and Application Security have the same end goal: making sure unacceptable amounts of software risk don’t end up in the portfolio. While the goals may align, the levers that one pulls to achieve them are wildly different. For this reason, SSCRM and AppSec are often handled in different ways by different teams, but firms are finding out that the lines in the sand drawn around each discipline are slowly eroding.
It’s springtime here in the south, and that means it’s bug season. Every season is bug season; it’s just a matter of which ones are in season. This year, like every year, I started by going to the outdoor section to stock up on ant granules, outdoor traps, door and window perimeter treatments, and other ways to repel insects in my yard. After that, I wandered over to the indoor section to grab the borax and sugar ant traps, spot sprays, and cleaning supplies to deal with any bugs that worked their way indoors. I was dealing with the same problem of bugs but in wildly different ways with different products and in different locations.
AppSec vs SSCRM have the same shared outcome, but different methods, locations, and tools. Just like a borax and sugar trap would catch ants out in my yard so well that it would be quickly overwhelmed or depleted, running automated security test tooling on all the code that’s out there in the open source community would quickly saturate the tooling and resources available to one company. Instead, areas of supply chain risk have different tooling and processes out there to deal with different areas and kinds of risk.
And there are different areas play in SSCRM. Each type of software and its source have unique risks, visibility problems, and control mechanisms that SSCRM teams have to account for. Let’s walk through Open Source Software, Bespoke Software, COTS software, and Partner Software to see what levers firms can pull.
Open source management has been the key focus area for many firms over the past five years. We’ve all heard the ancient rites of protection for this area: review and approve incoming open source software, store in a safe repository for internal use, scan with software composition analysis, and build a software bill of materials. That’s a good baseline, but do you want to make it better? Start vetting the open source projects. When reviewing the software, do more than look at existing vulnerabilities posted to the National Vulnerability Database (NVD) and check the license risk.
Examine the pattern of commits, is it one overworked individual or a team of regulars?
Are all the project sites and documentation up to date or do they redirect to parking sites?
Are existing CVEs closed out regularly, and do they follow a repeating pattern?
Could this package be subject to typosquatting, hostile takeover, or other library-driven malware attacks?
Was the last update made sometime this decade?
Bespoke or third-party software is like software your firm builds, but built by someone else. There is generally a contract bidding period and request for proposals, a negotiations period, and then after work milestones are hit, acceptance, and if you’re lucky, a support period. Beyond those steps, it may not feel like there is much a firm can do to enforce security on a peer. Just like you can’t bust your way into your neighbor’s kitchen and lay down sugar and borax traps for them, you can’t show up to a contract developer’s site and start running SAST tooling. Instead, you have to communicate, observe, and test what you can.
During the RFP phase, include vendor vetting questions: do they have a secure development lifecycle in place? What testing methodologies and secure coding standards do they adhere to? What testing artifacts do they offer up? Can they spell SBOM? What are their developers trained in?
During the contracting phase, communicate expectations about compliance with industry best practices, or even NIST’s Secure Software Development Framework. Don’t just front load expectations onto their build and dev process, set out expectations for what acceptable looks like to security and how the vendor will respond to bugs that are discovered after delivery.
Before accepting the code, test what you can. Run a binary scan or dynamic tests to ensure the executable deliverable runs as expected. If source code is provided, scan it.
COTS software is the toughest nut to crack. Nobody is going to get Adobe, Microsoft, or other behemoths to change the way they develop their flagship products for a single contract. Instead, dig into threat intelligence feeds that mention the products and find other firms that have already analyzed and secured installations. This is where having an active threat intel capability that participates in industry events is vital. Follow best practices, consume and emit intel, and patch whenever is most inconvenient for the bean counters in accounting so they know you’re doing something.
The newest category in this discipline is the platform partner. Cloud partners, PaaS, SaaS, Tacos-as-a-Service vendors, cloud-hosted CI/CD toolchain providers, cloud-based scanners, AI-driven tooling, are all software packages that run on Somebody Else’s Computer. The process here combines a little bit of all three of the previous areas. It takes the research and vetting required for selecting open-source packages and libraries and shifts it to a cloud install. It pulls the expectations management and SLA considerations from bespoke and third-party development and places those responsibilities on cloud or development teams to understand precisely what responsibilities are shared with “us” and shared with “them”. Finally, it takes the threat intel and industry participation requirements from COTS vendors and brings them to the cloud team because nobody is going to get AWS to radically change things for a single contract. Don’t forget the privacy concerns - any data you are providing to a partner is leaving your perimeter and you need the contract and vendor assurances it will be safe.
The lines between Application Security and SSCRM are blurring. There are new stakeholders who are responsible for reducing software risk across the whole portfolio, and it’s time to start collaborating. Any gaps in ownership or responsibility for security or risk can give attackers a foothold or allow risk to blossom and thrive.
There's always more words to spend on a topic like this one, but I've hit my budget for now. Stay secure, and never forget the humans.