I guess this is growing up: Coming of age with CISA’s Secure-by-Design Guidelines

With the downward pressure of a global recession, inflation, and general post-pandemic turbulence underpinning disruption to multiple facets of life, it seems only fair that we in the cybersecurity industry would eventually feel the winds of change. We have rolled with the punches of escalating cybercrime and data breaches, existing as the collective, fragmented sheriff of a digital Wild West, and it’s high time we updated our strategy for safeguarding software from bad actors who seek to do widespread harm.

The recently released National Cybersecurity Strategy signals the need for a seismic cultural shift for most companies, with the most glaring recommendation coming in the form of security accountability falling primarily on software vendors. This is a positive step, though it is sure to cause teething problems, especially as many organizations struggle to accurately assess their security maturity across the board, particularly among the development cohort.

Since CISA Director Jen Easterly’s trailblazing speech on secure design principles, we have eagerly awaited formal guidelines on how exactly organizations can approach this significant restructuring of software development as we know it. Thanks to a collaborative effort between the cybersecurity authorities of seven countries, we have a rather comprehensive overview of how to drive down vulnerabilities in software.

This should be cause for celebration, but understandably, there is hesitation building around how this will impact innovation, feature delivery, and, ultimately, the bottom line as the pressure of security stewardship mounts for vendors. We’ve grown accustomed to dealing with cumbersome tooling that is ill-fitting with developer workflows, overwhelming them with a list of fixes in an information avalanche. Add SCA and SAST scanning, and you’ve got thousands of identified issues in a codebase that are just not practical to solve. 

Despite this, in terms of our collective attitude towards code-level security, is it time we grew up and faced the music?

Security commitment and transparency boost our potential

Back in March, the White House announced with great fanfare that one of its top priorities in the National Cybersecurity Strategy was to shake things up and start holding entities liable for sloppy software security measures that see the light of day:

“Companies that make software must have the freedom to innovate, but they must also be held liable when they fail to live up to the duty of care they owe consumers, businesses or critical infrastructure providers,” the White House noted in the strategy.

In the era of “speed at all costs” software development, my opinion may be unpopular, but I truly stand behind the idea that coding with security front-of-mind from the beginning is the only way we safely create our digital future. We were already facing insurmountable challenges with data breaches, Nation State attacks and infrastructure disruption, and that was before code-capable AI tools hit the mainstream. Until every person touching code cares more about the security implications of their actions, we will continue to see cybersecurity issues surge at a rapid rate.

I know this is easier said than done. I have a lot of empathy for those standing at the bottom of a steep mountain to climb in order to change the conversation around security accountability, and enable developers in their organization to share responsibility. To adequately fulfill key secure-by-design principles in software development, It is going to require precision training that establishes a basic skillset, before deep-diving into more advanced security architecture methods. Developer-led threat modeling is a golden opportunity for the AppSec and development teams to work together towards a common goal, and explore access control and insecure design pitfalls that plague less mature organizations.

Still, the core issue has always revolved around a lack of ownership for security - until something goes wrong, then it’s the AppSec team left holding the bag - coupled with a low appetite for best practices to be established and executed across every part of the SDLC. The truth is, it was never acceptable for developers to start coding with so little security practice, nor for us to focus on speed and functionality at the expense of safety and quality. Yet, here we are, and this is our crucible moment to accept shorter-term pain for long-term ongoing success.

We should want to create the most secure, robust software possible, and the “radical transparency” called for by Jen Easterly is a boon to vendors and clients alike. It is definitely a mark of value to showcase the company’s security prowess, and brand trust and reputation are everything in this hyper-competitive landscape. 

Developers need our guidance and support to thrive in a secure-by-default environment

The guidelines pay particular attention to open-source and third-party components, both of which are widely used in most software development. It is imperative that developers are sufficiently security-aware to navigate potential inherent bugs with any pre-existing code they utilize. However, in addition, they must be able to apply working knowledge of security fundamentals in the languages and frameworks they actively write in every day. Annual compliance videos played at 2x speed won’t cut it; they need training and a tech stack that is hyper-relevant, easy to access without context-switching from their workspace, and ultimately, drives them to apply secure coding best practices as second nature. 

They cannot do this alone, and they can’t be expected to upskill in their own time. The cultural shift required to make the development team a fundamental cog in a thriving security program takes courage, time, and commitment, but the reward is cohesion between AppSec and developers that would have been virtually impossible a decade ago, and software that stands above those who are, in one way or another, happy to let security slide despite the chaos that could come to pass in the event of a worst-case scenario. 

I guess this is what growing up looks like for all of us in the software industry, and it’s crucial if we want to stop the same old vulnerabilities that have plagued us for so long, they too are old enough to drink.