Written by Travis McPeak, Resourcely CEO.
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.
Secure-by-default
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.
New technologies
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:
Netflix’s Lemur: makes it easy for a developer to get a TLS certificate for a microservice, without having to deal with cryptography, manage private keys securely, and remember to rotate certs before they expire
Google’s Safe Golang Libraries: protect against common issues such as YAML injection (see also Google’s Secure by Design)
See Clint Gibbler’s full list of secure by default libraries here
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.
The new security team
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:
- Shift from a reactive, issue-centric view of the world to a proactive, preventative strategy
- Aggressively embed linters, context, and other in-IDE tech to help developers deploy securely at development time
- Utilize secure by default libraries and frameworks that make classes of vulnerabilities impossible
- Implement backstops and guardrails that preserve optionality by developers, while preventing incorrect configuration 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.
DevSecOps: Can it be saved?
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.
Originally Published Resourcely Blog.
Top comments (0)