The conversation surrounding DevSecOps – the concept that security should be part and parcel of software development operations, rather than existing in a separate “silo” – may feel like old news at this point. It has been happening for several years, and most developers now realize that it’s important to integrate security into the CI/CD process.

Yet what many teams are still struggling to wrap their heads around is how they should go about implementing DevSecOps. It’s one thing to discuss integrating security into CI/CD, but another to figure out practical approaches to doing so.

This article explains one key strategy for implementing DevSecOps: logging. As we’ll see, effective logging from across the CI/CD pipeline helps lay the foundation for a development operation that bakes security right into the CI/CD process and enables the type of collaboration between all stakeholders that is essential for DevSecOps.

What Is DevSecOps?

In a nutshell, DevSecOps is the integration of security processes into the software delivery process.

Put another way, DevSecOps means tightly coupling security operations and software delivery operations. It’s an effort to extend DevOps – which emphasizes integration between development and IT operations – to include security.

A result of DevSecOps is that security stakeholders – such as security engineers and security analysts – participate centrally in the software delivery process rather than being handed code after it has already been written and told to secure it.

Importantly, DevSecOps is not a specific tool or even a singular practice. We can leverage many tools to support DevSecOps, and there are multiple ways to build security into a software delivery pipeline.

Logging as a Pillar of DevSecOps

No matter how you approach DevSecOps, it’s hard to imagine an effective strategy that doesn’t include logging – not just for production applications and the infrastructure that hosts them but logging across the entire CI/CD pipeline.

In a variety of ways, logging reinforces the practices and goals at the heart of DevSecOps.

‍

Shared Visibility

You can’t practice DevSecOps if your developers, IT engineers, and security engineers lack shared visibility into the state of each application release and which features are coming next (and therefore need to be secured).

You could try to gain this shared visibility by asking the various stakeholders to collaborate manually. They could hold meetings, chat on Slack, and so on. Yet while some live collaboration is always helpful, you’re unlikely to be able to achieve complete shared visibility through manual collaboration alone.

That’s why it’s also critical to leverage logs as a single source of truth to provide visibility into the pipeline. When security engineers, developers, and IT engineers have access to log data from across the pipeline, they can use that data to assess its state. As a result, they are better able to find security issues that other stakeholders may have overlooked and prepare for whichever security challenges may come next as they test, deploy, and write new code.

‍

Fast Resolution of Security Incidents

Along similar lines, when a security issue arises in production, developers, IT engineers, and security engineers and analysts need to react quickly and efficiently to resolve the problem.

Here again, logging is critical for enabling fast and coordinated responses. Waiting on manual sharing of sensitive data can slow down reaction times. But when every stakeholder can get the data they need from logs, access to information is no longer the weakest link in the security incident remediation process.

‍

Continuous Improvement

Like DevOps, DevSecOps emphasizes the principle of continuous improvement, meaning that security operations should become more effective over time and able to accommodate more and more types of threats.

It’s impossible to know how well your team continuously improves on the DevSecOps front without log data. Using application logs to track metrics such as the frequency of security vulnerabilities within each application release or the number of security bugs per line of code enables teams to log data about the CI/CD pipeline and security operations. Ultimately, this increases developers’ ability to track the effectiveness of detection and remediation efforts.

How often do you perform rollbacks in response to a security issue? How long does it take to detect and remediate vulnerabilities caught in the pre-deployment stages of the pipeline? By tracking metrics like these, teams know whether they are trending better or worse in their ability to find and manage security issues, which is one vital proxy for overall DevSecOps health.

Conclusion: Logging as a Key to DevSecOps

Again, there are many ways to implement DevSecOps, and many resources to drive DevSecOps success. Some will vary depending on the nature of the software delivery pipeline. For example, a team that deploys to Kubernetes clusters in a public cloud will rely on somewhat different DevSecOps tools than one that deploys to on-prem VMs, because the security vulnerabilities and metrics associated with each environment vary.

Virtually any organization and any type of CI/CD pipeline requires logging for an effective DevSecOps strategy. Logging provides shared visibility, easy access to information, and self-assessment opportunities, all of which teams need to make the most of DevSecOps over the long term.