How adopting a security first mindset improves everything
It's time we stop tacking security on "at the end" and start adopting modern best practices. Capture your control processes and integrate security into your SDLC from day one.
I love this post by Tiexin Guo. He’s spot on about how we need to approach security in the modern software development era. As he points out, the “old way” of tacking security on “at the end” of a project is just not viable. Likewise, doing it manually with hands-on-keyboard testing won’t cut it.
Today’s software architectures are too complex. The “old way” might have worked well enough for single-server monoliths where everything was self contained. Today there’s just too many disparate and fast-moving parts to be successful with a dated security model. Instead of a single language, a single database, and a single front-end we’ve got multi-cloud distributed deployments, often dozens of components and sometimes even a dozen languages and scripting dialects — all in a single application.
Teams are bigger today, too — an expected consequence of emerging complexity. A small team of 20-30 people in the 90’s has today morphed into a much more distributed, loosely associated group. That 30 person team might now look like 8-10 different teams, each with 6-10 individuals cranking away on code.
Everything is more complicated, and manual process tacked on at the end just doesn’t cut it. As Tiexin writes in his post, the solution is modern DevSecOps — shift all those control processes left, and automate:
Shift left: Why does security work at the end of the project, risking delays and rework? To change this, we want to integrate security work into every stage of the SDLC: Shifting from the end (right side) to the left (beginning of the SDLC, i.e., planning, developing, etc.), so that we can discover potential issues earlier when it’s a lot easier and takes much less effort to fix or even rework.
Automation: Why do we do security work manually, which is time-consuming, error-prone, and hard to repeat? Automation comes to the rescue. Instead of manually defining policies and security test cases, we take a code-based approach that can be automated and repeated easily.
As he succinctly points out:
If we combine the “shift left” part and the “automation” part, bam, we get DevSecOps: a practice of integrating security at every stage, throughout the SDLC to accelerate delivery via automation, collaboration, fast feedback, and incremental, iterative improvements.
His point about automation mustn’t be understated. Without applying automation in today’s complex SDLC pipelines, security as code (SaC) is just not going to work. Everything needs to be automated, especially anything that moves code from lower environments (like development) to higher environments (like production). Nothing should be allowed using manual actions. Instead, adopt a mindset of, “test batteries are the only path to higher environments.”
Likewise, he’s hit the nail on the head when it comes to the benefits of adopting Security as Code. Specifically, he points out how SaC will boost efficiency, create repeatability, reusability, and consistency in your deliverables, and ultimately accelerate the team and reduce costs. I’ve posted about those benefits before and will surely do so again.
Tiexin’s post is thorough and well worth the read — I highly recommend it, including diving deep into his linked posts.
I would just add, don’t stop with security. Everything should be automated, from your code and your runbooks to your entire delivery chain. Live and die by the rule that the only path to higher environments is through automation.