Press Release
Last Updated on January 19, 2024
The Executive Order 14028 from May 2021, on “Improving the Nation’s Cybersecurity,” directed the National Institute of Standards and Technology (NIST) to refresh NIST SP 800-218, now the Secure Software Development Framework (SSDF) version 1.1.
The SSDF makes “recommendations for mitigating the risk of software vulnerabilities” that are intended to be applied across the US government’s software supply chain, as well as critical infrastructure orgs and other public companies. Per other directives in the executive order, software vendors serving the US government will soon be required to demonstrate SSDF compliance. So, what’s the “lift” required to get there?
To talk about the SSDF from all angles, including what it takes to implement it, Elzar Camper, Pivot Point Security’s Director of Cyber Security Solutions & Practices, joined a recent episode of The Virtual CISO Podcast. The show is hosted by John Verry, Pivot Point Security CISO and Managing Partner.
Timeframe to assess gaps
If you’re just starting out with adding secure software development practices to your software development lifecycle (SDLC), how long might it take to assess your current program, plan and execute your remediation steps and achieve provable compliance with the SSDF?
“The quicker part is going to be the gap assessment,” Elzar advises. “That’s a couple of weeks. You’re looking at, ‘Okay, this is our program. Here are our policies and standards. Here are the people who develop the software… It’s traditional gap assessment, like you’re going to do with any other framework. I think the tough part is making sure the scope is correct and the boundaries are setup correctly.”
It can be challenging to determine which applications or development units specifically fall under “critical software” or otherwise need to meet the SSDF standard.
“I think the first conversation you have to have is that important scoping and boundary conversation and the understanding of, ‘What is the application doing? What kind of data does it host? Who are you selling it to, or who else is using it?’”
Orgs that may have aligned their SDLCs with other frameworks like BSIMM or the OWASP ASVS will need to perform a mapping exercise to identify gaps or differences in terminology. The SSDF supports this with built-in mapping tables that relate its practices and tasks to relevant parts of other frameworks.
Timeframe to remediation
As you might expect, it will take a lot more effort for most orgs to remediate their SSDF gaps than to identify them. If you’re starting from scratch, how long would it take to change, or create for the first time, all the applicable SDLC processes, policies, standards, etc.? And then train everyone on the development team?
This is typically months of effort, because you’re changing how people work together and how the development pipeline operates. You might also need to onboard or train new skill sets. Then you’ll need to operate the new process for some time to see if it’s working as planned.
Another common time impact is whether you must wait on budget to make the necessary changes.
“Let’s say they’re working in a particular programming language, and there may be only one or two automated code scanners that really will be effective for them,” posits John. “You can spend $50,000 or even six figures on a code scanner. If you don’t have that money budgeted, you might have to wait a year to get that budgeted.”
Talent acquisition challenges
If you need more people or different skill sets to achieve SSDF alignment, how/when can you fill those roles? DevSecOps experience being even harder to find than DevOps experience, can you hire the right talent to operationalize your plan? And/or train the people you have? Or augment your team with third-party expertise, from a vCISO on out, on demand?
“Application security engineers and that level of individual is extremely hard to attract and retain,” acknowledges Elzar. “The larger companies, they’re going to be fine. They have larger budgets. Where I think the challenges are really going to present, like they’re presenting for things like CMMC, is the SMBs.”
Customizable based on risk
How does a small to midsized business, when they might have a very informal methodology for their SDLC, take something like the SSDF and put this formality around it?
Elzar explains: “The nice thing is the SSDF doesn’t tell you how to do everything. It’s practices and it’s tasks, and it’s really outcome focused. If you take the risk-based approach of saying, ‘This is why we do it this way,’ or ‘This is why this works this way,’ it doesn’t have to be prescriptive to every possible reference control within the SSDF. It can be customized to the environment based on risk.”
What’s next?
To hear this show on the SSDF all the way through, click here.
What tools and controls can help most to rollout DevSecOps? Here’s a blog post on that topic: DevSecOps Tools – 4 Key Controls and How to Implement Them
