By: Chris Tozzi

Read Time: 7 min

Logging is probably not the first item to come to mind when most of us think about DevSecOps, a term that refers to the integration of security into DevOps processes, but it should be. Logging and log management play a critical role in helping to put DevSecOps principles into practice by ensuring that developers, IT operations staff, and security teams have the visibility and communication pipelines they need to prioritize security at all stages of the DevOps delivery cycle.

Logging for DevSecOps

What is DevSecOps?

DevSecOps means making security part and parcel of all DevOps practices, from code development and integration at the start of the application delivery pipeline through to deployment and management at the end.

The term has become popular as a way to emphasize that DevOps should not just involve better integration between development and IT processes (which is the classic definition of DevOps) but should extend to security, too. Otherwise, the argument goes, security exists in a silo and ends up becoming an afterthought when code is written, tested, and deployed.

What it Takes to “Do” DevSecOps

Like other DevOps principles, DevSecOps is a philosophy rather than a specific set of practices. There are many paths that teams can take to “do” DevSecOps, and many tools that will help them get there. Thus, it would be wrong to think of DevSecOps as something that you achieve by implementing a certain process or adopting a certain tool.

At the core of any healthy DevSecOps strategy, however, are two key principles:

  1. Seamless communication between the development, operations, and security teams. It’s only by being able to communicate and collaborate that each of these groups can work together to improve the overall security of DevOps processes.
  2. Across-the-board visibility into security considerations. This means that security issues, or potential security issues, that exist at any stage of the application delivery cycle must be easy to identify. It also means that all stakeholders—developers, IT engineers, the security team, and anyone else—have constant visibility into the state of the delivery cycle and can, therefore, identify and respond to security concerns readily.

Logging and DevSecOps

Logging and log management play an essential role in achieving both of these principles and, by extension, in enabling DevSecOps.

Communication Between Development, Operations and Security

When it comes to communication between different teams about security, log data functions as a single source of truth that all parties can use to identify, respond to, and discuss security considerations.

Whether you’re a developer, an IT engineer, or a security engineer, you know how to work with log data. In fact, logging is one of the few tools and skillsets that all three of these disciplines share.

Thus, by using logs as the basis for communication, it becomes practical to operationalize DevSecOps. If a security engineer wants to discuss a potential vulnerability with development or operations, he or she can point to log data to identify the event and convey relevant information. This technique is much more effective than attempting to have developers or operations staff work through security tools they are not accustomed to using.

It’s important to note that simply collecting logs is not enough to facilitate DevSecOps. Managing the logs effectively—in a way that allows all stakeholders to see relevant trends, contextualize events, and pull out the information they need to perform a certain task—is also essential.

Security Visibility

Logs also form a common foundation for providing visibility into potential security considerations related to software. No matter which stage of the application delivery cycle you are working with, you can generate and analyze log data to help identify security risks.

Logs from a CI server could be used to identify anomalous code integrations that merit further investigation. Logs from application tests and builds provide an opportunity to evaluate how software runs, and find potential vulnerabilities, before deployment. Logs from production environments, of course, offer the greatest degree of visibility into security issues that may arise once the latest version of an application is up and running.

In this way, logs make it possible to understand the security context of software at all stages of the DevOps pipeline, which is exactly what DevSecOps is all about.

Here again, of course, merely generating logs is not enough. It’s also critical to have an efficient log management strategy in place so that log data from the various stages of the pipeline can be aggregated and analyzed effectively.

Conclusion

It would be an overstatement to say that logging and log management are the only essential ingredients in DevSecOps. A lot of other factors come into play in order to achieve a successful DevSecOps culture, such as obtaining buy-in for security by all members of the IT organization.

However, logging and log management are a critical facet of DevSecOps, and ones that have perhaps been underappreciated. You can’t do DevSecOps if you don’t manage logs effectively. If you are wondering how to put DevSecOps principles into practice, your logging strategy is a good place to start.

This post is part of a larger series called Logging in the Age of DevOps: From Monolith to Microservices and Beyond.  Download the full eBook here.

About Chris Tozzi

Chris Tozzi has worked as a journalist and Linux systems administrator. He has particular interests in open source, agile infrastructure, and networking. He is Senior Editor of content and a DevOps Analyst at Fixate IO. His latest book, For Fun and Profit: A History of the Free and Open Source...

RELATED POSTS

Logging Best Practices Part 5: Structured logging

Isn't all logging pretty much the same? Logs appear by default, like magic, without any further intervention by teams other than simply starting a system…...

Engineering

Logging Best Practices Part 4: Text-based logging

Isn't all logging pretty much the same? Logs appear by default, like magic, without any further intervention by teams other than simply starting a system…...

Engineering

Logging Best Practices Part 3: Text-based logs and structured logs

Isn't all logging pretty much the same? Logs appear by default, like magic, without any further intervention by teams other than simply starting a system…...

Logging