Developers, when you hear Security, think Quality

Since the introduction of agile development methodologies and automation in the form of CI/CD, engineering excellence has largely focused on velocity and quality as the metrics of elite engineering teams (or as DORA Metrics define them - velocity and safety). It’s only natural, then, that while security teams have concentrated on risk reduction –– these two worlds in their evolution diverged completely, and oftentimes, security came at the expense of meeting these engineering metrics. This siloed approach eventually left security behind in the native SDLC but also had the byproduct of culminating in painful vulnerabilities, breaches, and downtime. 

A common mantra you’ll hear from security practitioners is that for security to be truly effective, it must be integrated into the development process as a shared responsibility –– but everything breaks down around the “how” when the “what” is obvious. While developers are no fans of hype cycles and buzzwords, there is an emerging category that sounds slightly academic and business-centric called “Application Security Posture Management” (ASPM) with the main goal of providing a high-level view to the end-to-end security management of the application, which today should be as critical to engineers as application quality and performance.

The entire (x)SPM category which includes everything from DSPM and CSPM (data and cloud posture management respectively), are currently "artificially" distributed into subcategories, despite the fact that they are tightly coupled when it comes to applicative security posture management.  That is why, at Jit, we foresee a convergence of these subcategories into a comprehensive (x)SPM domain,  that will be centered around the app and everything it requires to run—data, cloud infrastructure, identity, and everything else. 

This converged ASPM category is just the first step toward finally removing the friction, focusing on developer experience, and making security a first-class citizen in the software development lifecycle––as it very well should be. Emerging categories like Platform Engineering only strengthen the need for everything from the infrastructure through the code running on top (and all the middleware services in between) to improve visibility (service catalog), quality (scorecards), and standardization through templating. 

That’s why in this post I’d like to argue that security IS QUALITY.  They are one and the same, and once engineering organizations understand this, and make this mind shift, security will inherently be a part of the SDLC and not a best external effort to delivery.

The Evolution of Testing and Quality Assurance

This mind shift is not a new one.  There are entire categories of engineering that underwent similar evolutions. Take quality, which today, is a defining metric for engineering excellence.  Historically, testing and quality assurance (QA) were often seen as separate from development, with dedicated QA teams responsible for automated testing, and then manual validation. However, this approach proved to be a bottleneck, slowing down the development process. The advent of automated testing, including unit tests, integration tests, and end-to-end (E2E) tests, revolutionized the way we approach quality. Automated tests increased velocity significantly and demonstrated that developers could and should take ownership of their code quality by writing their own tests.  

By removing this friction, and making it a native part of development practices, with entire disciplines built upon it - like TDD (test driven development), this shared ownership of quality, took engineering lightyears forward.  But how was this practically achieved? 

Automation of course.

Automating Code Quality for Engineering Velocity 

Automation needs to be useful and high quality for it truly to be adopted, and integrated into engineering processes (and we’ll touch on where this broke down in the security-sphere until now). When possible, in order to maintain high code quality, developers adopted various automation practices to enforce good code quality.  Like all automation, this reduces human toil and error by ensuring that repeatable processes are implemented in the exact same manner every single time.  

This was accomplished by enforcing simple engineering practices like automating linters, standardizing code, and using templating and boilerplate code. These practices not only improve code consistency but also enhance overall efficiency. 

Platform engineering has taken these principles further, creating self-serve infrastructure and development environments that replicate these benefits across the entire engineering process.  So in the platform engineering world, instead of writing the same project templates, customizing and re-customizing the same processes and workflows, continuously fiddling with CI/CD setups, as well as governance, compliance, and policy enforcement––all of this can be baked into developer portals that are growing in popularity like Backstage (OSS) or Port (commercial).

Security as Quality

Security has traditionally been viewed as an external responsibility, often managed by the Chief Information Security Officer (CISO) with a separate security team. However, for security to be effective, it must be baked into the development process from the beginning. 

Where “shift left” as a paradigm breaks down, "security by design" comes in to ensure that security measures are integrated into the software development lifecycle (SDLC) and become a default part of the development process. This practically means that security and engineering teams should work together towards this end–not just shift responsibility from one to the other.

Platform engineering is also impacting the approach and culture around security.  Where popular platforms now include tabs dedicated to security as a metric for service and production readiness that are not decoupled from a common quality and applicative overview. 

This is exactly how security should be viewed and implemented across engineering organizations, as another equally important box to tick before deploying to production. Not as an afterthought, not as point in time security that comes too late, but part and parcel to engineering across the board and its metrics.

ASPM tools (like Jit) are paving the way towards this transition. The idea, just like an IDP, is to provide a centralized view of the application's security posture, allowing developers to address security issues as part of their regular workflow. This can be done by integrating into existing platforms like Backstage or vice versa, for ASPMs to integrate IDPs into the platform. Think ASPM is to security engineers, as the IDP (internal developer portal or platform) is to platform engineers.

This will make it possible to automate security checks and integrate them into the SDLC, where forward-thinking ASPM tools enable security to be treated as a quality metric, much like code quality or performance. At Jit, we have also been working hard to be able to quantify these metrics, not just talk about them qualitatively. 

We have spoken about security DORA metrics before, and today we have been witnessing firsthand, measurable security and code quality improvements for many engineering teams when metrics like Mean time to Mitigate (MTTM) are measured alongside Mean Time to Recover (MTTR), Security Issue Density (vulnerabilities per lines of code) alongside Change Failure Rate, and overall team security scoring, alongside overall velocity and quality.

This means that when we look inside our IDPs and check our scorecards when it comes to performance, service readiness, and quality, we should have security included in these scorecards. This is just the end goal, we also need to ensure that security is enabled by the right tools and rituals throughout the SDLC, viewed as equally important aspects in our IDEs, SCMs, IDPs alongside our agile rituals.

The Imperative of Automation

In our fast-paced, event-driven, microservices-based cloud-native world, everything that can be automated should be automated, as there are more platforms, applications, and services than humans to run them. This principle applies to security as well. Automated security tools and processes ensure that security measures keep pace with rapid development cycles, providing continuous protection without slowing down development. But there is also a dark side.

Much of the disdain around security automation has been due to the low-quality application of automation.  Remember high quality and useful? While many tools have popped up over our cloud-native evolution, they also brought with them a lot of noise and cognitive load for developers.  In the same way that DevOps underwent leveling up with better monitoring and alerting platforms to reduce alert fatigue, security tools and platforms need to also focus on the security experience when building automated tooling.  Offloading the toil to developers renders these tools useless and they are ultimately bypassed. Security priority and context need to be the backbone of security automation tools–and doing this right is a whole blog post unto itself (which will hopefully come soon).

Security = Quality + Velocity Which = Platform Engineering 

Platform engineering represents the next evolution of DevOps, providing a holistic view of the application from an engineering perspective. Security is just one of the many parameters that determine an application's readiness for deployment. By adopting a service-oriented approach, where teams own their services end-to-end, including security, organizations can achieve true shared ownership.

The integration of security into the development process as a shared responsibility is no longer “nice to have”, but on-par with other business critical metrics in modern software development. By leveraging ASPM tools, and embracing platform engineering principles, organizations can ensure that security is treated as a quality metric, integrated seamlessly into the SDLC. This approach not only enhances security but also improves overall development velocity and efficiency, ultimately leading to higher quality and more secure applications.

In the end, the key to scaling security is this shared ownership which will eventually propagate to groups and teams just like all other aspects of security ensuring real engineering ownership–not as a buzzword or loaded practice like shifting security left, to be someone else's problem that just increases the backlog of security debt. By making security an integral part of the development process, we can ensure that it keeps pace with the demands of cloud native operations and software development within existing workflows, processes and team dynamics, providing continuous protection as the means to achieving speed and quality.