After years of headline-popping software supply chain–related breaches — think SolarWinds, Log4j, 3CX, and MOVEit — software security advocates agree that organizations have to change the way they tackle application security (AppSec).
The overriding consensus from the experts is that software producers need better software development practices, such as following Secure by Design, which was proposed in April by the federal Cybersecurity and Infrastructure Security Agency (CISA). The idea of Secure by Design is relatively simple in principle, if difficult in practice to achieve. Security should be baked in at the conception of software, and security functions and parameters should be designed, architected, and coded into the software at every stage of its lifecycle. It advocates security education for developers, varied and thorough testing and detection of vulnerabilities during every step of the lifecycle, and security guardrails that make it easier for developers to code securely.
Secure by Design also ideally takes AppSec far beyond trying to code software without security bugs. Most longtime AppSec advocates explain it means hardening application infrastructure, architecting secure data flows, designing solid permissions and identity management into software, and establishing guidelines for secure configurations and deploying them by default.
These Secure by Design principles are the first step in transferring the responsibility of keeping software secure from the consumers of that software — who are constantly called to patch or remediate faulty software from their suppliers — and back onto the shoulders of software producers.
But Secure by Design is easier said than done. Open-source project leads, commercial software development companies, and internal enterprise software engineering teams all must battle against AppSec inertia. Developers and AppSec pros alike still contend with ingrained software development patterns and legacy tool sets built for a more reactive approach to AppSec.
The reality: Software security practices are mired in after-the-fact application security testing (AST) and scan-and-fix cycles, fixations on legacy vulnerability management programs, and endless patch cycles. Additionally, some security pundits believe that CISA's Secure by Design guidelines don't yet address the complexity of the modern software supply chain.
Here's what's holding back Secure by Design's potential, and how software security can move forward.
[ Learn why you should go beyond the SBOM with our Special Report. Plus: Download the White Paper ]
Holistic AST is key
Saša Zdjelar, Chief Trust Officer at ReversingLabs and a longtime security practitioner, said the work by CISA to publish its seminal paper on Secure by Design helped mature industry conversation about software security. But there's still a lot of work needed before these principles, and the practices around them, can address the complexity of securing software today.
"That paper and the months of work put into it was good, but I'd argue that it still predominantly focuses on a very narrow set of problems that can come out of software. And, unfortunately, it's not the type of stuff we've seen in the largest breaches, recently. These breaches are caused by software supply chain ripples. 3CX and SolarWinds have more to do with malware implants and integrity issues than traditional vulnerabilities."
—Saša Zdjelar
Those types of supply chain weaknesses can't be found through traditional AST tools or software composition analysis (SCA), Zdjelar said, "because that's just not what they’re designed for." He said Secure by Design is still too wedded to traditional AST and SCA without encouraging better context of how software is compiled and deployed.
For Secure by Design to deliver on it's promise, organizations need more holistic tools that work for producers and consumers of software, Zdjelar said. He explains what he means by holistic AST by describing what crash tests did for ensuring the safety of cars.
"You crash-test it, and then you provide the insights into how it did from various angles at various speeds, airbags, crumple zones, all those sorts of things that we have agreed are the characteristics of a secure vehicle or a safe vehicle. But you wouldn't crash-test a radio volume knob and a windows up-down button and a seatbelt separately and a rear car seat separately and a visor separately. You crash-test the vehicle when it's been fully assembled so that you know how the system as a whole operates or will perform in that type of environment."
—Saša Zdjelar
One of the big problems with the shift-left movement of recent years, Zdjelar said, is that it focuses too intently on component views to the detriment of understanding the context of how it all operates in the completed software package. When Secure by Design is fully realized, the benefit will be early analysis while also doing integrity checks that ensure the crash-worthiness of software before it is shipped.
Incentivizing developers is essential
Another big impediment today is that, no matter how comprehensive or well-thought-out a Secure by Design framework may be, it won't count for a whole lot if developers aren't properly incentivized to act on it.
Hughes said there's no real incentive for developers to slow down or integrate more security, which they often view as friction.
"While security is the center of the universe for us security people, it is not for engineers and developers. One of the big reasons is that they're incentivized and graded in terms of performance based on other factors like the number of features that they push out or how effectively they bring down the backlog or their sprint velocity and all those kinds of performance metrics. They're focused on just getting things out as quickly as they can, and they align with the incentives of how they're graded."
—Chris Hughes
This is not the fault of the developers; it's a management problem. That is why Secure by Design demands that security leadership team up with business leadership to properly incentivize engineering.
Until development team incentives align with an organization's performance metrics, no behaviors are going to change, Hughes said.
"If security matters, we should evaluate people's performance on how they integrate security into the product development lifecycle or add security metrics as part of key performance indicators. It starts at the top, and it has to be institutionalized. Otherwise, nothing is really going to change."
—Chris Hughes
Sound AST methodology matters
On a more tactical note, Hughes cautioned that organizations that already have this kind of institutional buy-in still need sound methodology and planning to effectively execute Secure by Design. He recommended that organizations choose something such as the NIST Secure Software Development Framework (SSDF), which is mapped against the OWASP Software Assurance Maturity Model (SAMM).
Organizations that are still relying on legacy AppSec practices should switch to SSDF and SAMM for starters, Hughes said. "Ask, Are we using a secure development framework or methodology? And if we aren't, can we rally around one to start to integrate some of these security practices and techniques into our product development?"
However, Zdjelar said the guidance provided by CISA is "not even close to enough,” noting that the most infamous software supply chain attacks — 3CX, SolarWinds, and Kaseya — would have been missed.
“Not a single component of any of the AppSec programs currently listed in CISA’s guidance would have prevented any one of those.”
—Saša Zdjelar
Legacy AppSec tools find certain categories of vulnerabilities, "which are absolutely a concern, and should be worried about, but a holistic final exam for software is critical.
“What’s missing is the crash test for the system as a whole.”
—Saša Zdjelar
When product security met accountability
Effective product security leadership is another thing that is lacking in most organizations and that many experts view as crucial to Secure by Design. David Lindner, CISO at Contrast Security, said product security professionals need to be embedded in product teams.
"Product security plays a fundamental and significant role in making sure the core principle of Security by Design is followed. Secure by Design emphasizes integrating security considerations into every phase of a product's lifecycle, from its initial design and development to deployment, maintenance, and eventual retirement. Product security ensures that security is not an afterthought but an integral part of the entire process."
—David Lindner
Jamie Boote, an associate principal security consultant at Synopsys Integrity Group, said product security also can play a role in enablement. When product security is done right, the embedded security professionals can help bridge the gaps between security, engineering, and the business by reducing what Boote calls "cognitive friction," the mental effort it takes to understand and solve security problems.
"ProdSec can reduce cognitive friction that developers, architects, engineers, and other stakeholders experience by providing training, clear requirements, reusable solutions, and Secure by Design components that teams can adapt and use with minimal effort."
—Jamie Boote
The developer experience matters
The idea of easing the security burden for engineers stands at the heart of what Kymberlee Price, a longtime AppSec and security practitioner who recently started a security firm called Zatik, thinks is most direly needed to meaningfully enact Secure by Design.
"I'm honestly excited for Secure by Design as a concept being championed across the industry because that's the only way we are going to make a difference and improve security. I think we've well proven bolting it on after the fact isn't working right."
—Kymberlee Price
However, to help evolve the culture and mindset of engineers, she said, the security team needs to think about improving the secure developer experience.
"For security teams to actually execute on secure by design, we need to shift our mindset of how we create good security UX for developers. It can't just be, 'Do it because I said so.' We have to reach across the gap and say, 'I want to make this easy for you to do the right thing. Help me understand your business.'"
—Kymberlee Price
Open source isn't the whole AppSec picture
ReversingLabs' Zdjelar pointed out another weakness: The current iteration of Secure by Design planning is "hyperfocusing" on open-source software flaws.
"If we're talking here about how to secure enterprises, enterprises don't run on open-source software. They obviously have a lot of open source in use, but when you buy a product from SAP or you buy a corporate password manager or CyberVault, like a CyberArk or even LastPass, that is not open source. When you install Zoom in your environment, when you run Teams on your endpoint, that is not open-source software, and neither was SolarWinds Orion. So what runs enterprises is very, very large, complex commercial packages which may have some open source in them."
—Saša Zdjelar
Zdjelar said that for Secure by Design to be useful for an enterprise software portfolio, it needs to bring better visibility and vetting of commercial, off-the-shelf software into the mix.
Get your bearings on software supply chain security
Aquia's Hughes said organizations pursuing Secure by Design need to understand where they exist within the software supply chain, because that affects how they run components and how they ship their code.
"Everyone to some extent is a consumer of external software and products but also likely a producer of software and products that are being used either internally or externally by customers and consumers. And just understanding what your role in the ecosystem is and how you can strengthen those relationships and also be prepared if one of them has an incident so that it doesn't impact you or your stakeholders too much is part of the equation."
—Chris Hughes
