Shift Left, then Down!

Oftentimes in Cybersecurity, terms get thrown around as if everyone is assumed to know what they mean, and it becomes meaningless jargon! “Shift Left” is such a term, and while there are countless posts on the topic, let’s explore it from the lens of a Startup deploying global solutions. It can be the lifeblood, and when done right, the Holy Grail for Cybersecurity. It is one of the most important concepts for Cybersecurity and business application development because it allows for continuously embedding security into the solution, by design.

In this post, we’ll dissect the notion of “Shift Left,” and then interweave “DevOps” and “DevSecOps” into the story to round out the picture. It’s interesting, somewhat amusing, but mostly uplifting to see what in practice (“DevSecOps”) is what was dreamed of years ago with the vision of “S-SDLC”…but that’s a whole different story! We hope you enjoy this journey, and use it as inspiration to adopt a well-tuned DevSecOps practice!?

Modern development teams, and especially Cloud-first, disruptive companies are the early and best adopters of DevOps and now because being nimble means success or failure. If you’re in the game of deploying business applications today, they need to be massively scalable in seconds, alterable in hours and days, and able to withstand all manner of threats. DevOps is the most nimble path for engineering & operations teams to deliver these outcomes.? It’s often referred to as a culture instead of a model, is more dynamic than Agile, and introduces a clean pathway for collaboration and feedback from various stakeholders. Very simply, this is “Continuous Integration/Continuous Delivery” in motion.

With the old adage “an image is worth a thousand words,” the DevOps model speaks for itself!

Image Source: DrupalSun

The challenge for Cybersecurity in this model is the highly dynamic rate of change. Change increases the Threat landscape by introducing “unknown” and potentially “uncontrolled” assets into the operating environment. Introducing a new set of microservices with no configuration baseline enforcement, for example, leads to significant, unknown exposure to potential compromise. Legacy models & mindsets for addressing security no longer apply, and security teams must learn to become adaptive, responsive, and ingrain themselves into the DevOps process.?

This is exactly where the DevOps model shines! On the very “Left” of the model, we find “Collaboration.” In the standard DevOps model, this applies to our cohorts in the Engineering teams. But it is also the precise point-of-entry where teams can “shift” into the mode of DevSecOps, introducing security into the Build and Plan phases as a collaborative effort. This is absolutely the best position for security teams! And by extension - the business.

In our minds, security teams must earn the right to be at the DevSecOps table, and part of that is letting go of “no” and finding “good enough, we’ll come back to it” as an operating mindset. The ability to execute Threat & Risk Models dynamically within the DevOps process is as important as understanding the operating environment (code base + target infrastructure).

This collaboration is a beautiful operetta we’ve seen firsthand! DevSecOps teams write in all sorts of languages, push out infrastructure-as-code, and do really cool things with technology. Equally, they challenge security professionals to bring their A-game, accelerating the pace of achievements for businesses leveraging this model to deliver Cyber-resilience.

While the joys of operating in the DevSecOps fast lane are undeniable, let's explore the power of “shifting down” a gear to get real traction! Cloud-first organizations are built on code (i.e. DevOps) for business applications, including infrastructure, and Cybersecurity teams must drop deep into that technical stack to design security as a native element. This means understanding the target operating environment (no two Clouds are the same!), operating platforms & languages, and using that context to design the security specifications. In this world of microservices, things move extremely fast - but fundamental security principles still apply. In the DevSecOps model, Security becomes the wrapper encompassing Development and Operations. Nirvana!

Here is the very essence of “Shift Left.” Security requirements are developed, tested, and implemented along with the application codebase during the development phase. Both are deployed into the world of Operations, which is governed by security controls where monitoring and enforcement take priority. In the DevSecOps model, automation is paramount for all areas, especially Cybersecurity, driving the vulnerability, threat, and Incident Response processes. The entire model is driven by Continuous Learning and Continuous Improvement.

Shifting “Down” to our last Cybersecurity gear, it’s vital to recognize the software supply chain is a foundational component for DevSecOps. Open source and various libraries are used in software code bases as building blocks to create products/applications, and as we saw with Log4j, even the most secure code can be exploited if a weak component exists. Perhaps more importantly, understanding the license implications of the open source components might pose a greater threat than code vulnerabilities! For these reasons, software supply chains should be regarded with extreme importance, and code vulnerability programs should start with Software Composition Analysis (SCA).

SCA tools should be in every single DevSecOps toolkit, and are a more important priority than Static Application Security Testing (SAST) or Dynamic Application Security Testing (DAST) tools. SCA discovers open source modules, libraries, and other code snippets, creates Software Bill of Materials (SBOMs), and empowers DevOps teams to go down deep into their code to understand dependencies, license implications, and vulnerabilities. This brings security into the core of the DevSecOps Build phase: collaboration is highlighted to create processes for evaluating results and making risk-informed decisions about them. Building upon this capability to mature the code vulnerability management practice, the next logical steps are SAST, and DAST, in that order.

Now, a short segue into Compliance. Compliance simply means adherence to something - and that something could be a Control Framework (SOC2, ISO, HIPAA, etc.), or it could also be a design specification. In the DevSecOps model, Monitoring and Analytics can also be Compliance measurements in addition to operational metrics. These can be derived from tools and processes baked into the design, such as integrated GRC solutions for regulatory compliance, and more advanced nextgen tools for monitoring (and enforcing) configuration drifts and threat conditions with auto-remediation Runbooks.

To bring us home: “Shift Left” also implies that Senior Leadership will set the tone for a culture of Cybersecurity. Cybersecurity, like deploying new business capabilities, is an iterative process of improvement, not a singular project and destination. To evolve from DevOps to DevSecOps, it must be driven with directives and support by Leadership at all levels, measurable objectives, personal ownership, and budgetary allowances. ?Without these elements, our shiny new DevOps apps will be nothing more than a steel frame of potential, weak against breach attempts, and fully at the mercy of the Operations crew to fix a phenomenally complex problem without the right capabilities.

Whichever path you choose, to adopt DevSecOps or not, May the Force Be with You!