June 11, 2024
Travis McPeak
Secure defaults, the fix to broken DevSecOps
In part 2 of this series, I explored the promises of DevSecOps and where they went wrong. To wrap up this series, we’ll propose how to solve the current problems in security and software development and highlight some early success cases using this approach.
DevSecOps has two primary problems: we asked developers to be the primary owners of security configuration at the expense of their primary responsibilities, and we haven’t provided automation tools that can take SecOps off their plate.
The result? Developers are burning down never-ending tickets, going through tedious threat modeling exercises across all of their applications, and undergoing hours of training for all vulnerability classes.
The solution is secure-by-default: an approach that shifts responsibility onto systems, not people. Secure defaults integrate security and configuration guidelines into tools that developers are using, leveraging new libraries that make security the default, all supported by a new security team. In short, systems ****should be responsible for security, not people.
Secure-by-default can help developers move faster and reduce incidents by automatically taking care of secure configuration without requiring developers to make complex, nuanced decisions - and stepping in to help them, when they make incorrect ones.
The past ~10 years of DevSecOps have taught us some valuable lessons about developer behavior: they are not security experts, and they don’t like to leave their standard development and CI workflow.
To accomplish secure-by-default, any automated tooling needs to be embedded into existing developer workflows. This ranges from auto-suggesting security best practices within IDEs, to embedded context wherever configuration occurs, to using systems that make good security choices for you.
Some great examples of secure default libraries and systems are:
The second critical part of a secure-by-default platform is guardrails: policies and rules that proactively prevent misconfiguration, again embedded into the developer’s workflow. These are backstops that prevent developers from deploying vulnerable software, while allowing them to follow their existing workflow: developing locally, pushing to the cloud, using version control, and leveraging automated deployment tooling.
These embedded secure-by-default practices combine with guardrails that keep developers in track - resulting in a paved road to production. There should be paved roads across a variety of fields: infrastructure, application development, CI, and more.
Automated tools that can take cognitive load off of developers are only possible with a savvy security team that is willing to truly embed security where developers are. This team should:
The foundational work of security should be done BY a security team, FOR a developer team - shifting the burden of security decision-making from developers onto systems, and making the last mile work for developers painless.
These new automation technologies will allow a security team to become extensible, scaling with a development team by embedding into their workflows without having to add additional security resources and burning out developers.
Security teams have lagged their developer counterparts over the past 20 years, as cloud computing and dev practices have revolutionized the tech industry. While DevSecOps held great promise, it has resulted in the worst of both worlds: slow development, and frustrated security teams dealing with constant misconfiguration.
The next generation of security is secure-by-default. We have the tech, and we know what it takes to accomplish it - the only thing left is committed security teams helping embed secure-by-default into developer workflows.
Resourcely is working hard on this problem! To make your organization secure-by-default, get started with Resourcely and give your developer teams the security capabilities they need without leaving the tools they love.
