Image by juststock from Getty

By Asim Rahal, Freelance IT Consultant and Security Writer

If you’re a DevOps engineer, times have never been better. Almost every enterprise has adopted an agile release framework, giving those familiar with DevOps plenty of opportunity. However, DevOps has a brewing problem: Security.

Traditionally, security has been treated as an appendage in the DevOps pipeline, which has created massive risks for enterprises. As security’s “shift to the left” accelerates, you cannot rely on mere DevOps knowledge. 

Hailed by many to be the next stage in the evolution of DevOps, the DevSecOps approach calls for keeping security in mind at all steps of the software development and rollout pipeline. While data from Synopsys indicates that security testing has indeed increased at each phase of app build and release workflows, over half of the respondents to a recent Progress survey admitted that they don’t completely understand how security fits into DevSecOps

Here are five principles every DevOps engineer must internalize when upskilling towards DevSecOps.

1. Zero Trust (ZT)

Currently, the average piece of code might include several calls to microservices and apps hosted in other cloud containers. Infrastructure sprawl is common in modern organizations and doesn’t pose major risks by itself. However, implementing DevOps may end up introducing several risks, due to its prioritization of automation and speed.

Practically, DevOps-oriented coding teams find it easier to hardcode access credentials to ensure smooth execution in production. The problem is this method assumes everyone in a network deserves trust. This approach perhaps made sense in a largely analog world.

However, today’s automated pipeline must operate on a Zero Trust philosophy. ZT requires everyone to prove their trustworthiness before accessing key information. Sounds pessimistic, but it works. ZT protects organizations by assuming the worst every time, and DevSecOps cannot function without it.

For instance, agile security operations use tools that automate access authentication, instead of relying on hardcoded information. These tools offer the minimum required access and automatically terminate it once information is retrieved. 

Developers must mentally embrace ZT to succeed in a DevSecOps environment. Everything from their security templates to code structure changes when moving to a ZT framework.

You may be interested in 6 Tips For Building a DevSecOps Program

2. Container Orchestration

DevOps engineers are familiar with container orchestration and its benefits. However, orchestration has a few additional nuances in DevSecOps that traditional DevOps lacks. For starters, ZT will hugely limit who has access to containers and the time they have that access.

As a result, developers must account for automated services revoking access in code instead of assuming access will remain static, as is currently the case in DevOps. Some organizations even create whitelists with hashes and code, typing them into processes with sole access. Developers will thus find themselves on the wrong side of orchestrated automation more frequently in a DevSecOps environment.

Agile security systems like DevSecOps also segregate containers based on risk. Developers must familiarize themselves with concepts like namespaces that assign IDs to specific containers, defining who can access them and when. 

Cgroups are another feature that security teams use to control container access. Developers must work with their embedded security team members to understand how they work and which patterns security teams look for before shutting them down for abnormal behavior.

Security teams are far more active in DevSecOps, and this will pose challenges to developers unfamiliar with security needs. The key to working well within DevSecOps is to realize that security is a product feature as much as any functionality the product team identifies.

3. Chain of Custody

A chain of custody is a legal concept that defines how evidence moves through a system. It’s a real-world log of how important assets are handled in a system. A software chain of custody is similar, defining how a system was used, by who, and when.

Sounds simple enough. However, most developers lack security training, and processes originating from chain of custody implications might appear as less-critical hurdles. Modern enterprises that embrace DevSecOps document and audit everything connected to a system, including activities that take place outside the development pipeline.

For instance, developers must document all reasons for code changes and justify why they need access to certain software assets. These questions might seem intrusive if developers are unfamiliar with the chain of custody requirements.

Many enterprises use chain of custody logs to improve DevOps processes and increase efficiency. As a result, developers must learn to live with chain of custody rules and avoid an unstructured approach to code changes and enhancements.

4. Static App Security Testing (SAST)

Marrying testing with app development is the biggest challenge DevSecOps tries to solve. While automating security solves many issues, it relegates security testing to the background and turns it into an opaque box that developers lack access to.

SAST solves some of these problems by giving developers insight into which security vulnerabilities exist so they can fix them within the source code of applications or components. Developers receive almost instant feedback on weaknesses, along with recommendations and in-line suggestions.

Developers can easily navigate every line of code and scan them for vulnerabilities, leading to more secure apps. SAST is usually paired with DAST (dynamic application security testing), which tests APIs and other associated calls within code.

SAST is a great example of how DevSecOps brings security to the left and gives developers more exposure to security processes. Developers unfamiliar with DevSecOps and security principles might find SAST cumbersome at first, due to the near-instant security flaws it points out. However, recognizing that security is a product feature (not an appendage) will help them value SAST much more.

5. Software Configuration Management (SCM)

DevOps engineers are typically familiar with SCM. However, when security is added to the mix, SCM becomes much more than version control and git repositories. It brings code into the world of compliance and industry regulation. SCM is extremely relevant to developers working in highly sensitive industries that face tight regulations.

While SCM is likely to remain the purview of a company’s security team, developers must be aware of the process since they will feel the impact. Much of SCM ties into attack surface management, and developers must create code with those implications in mind.

For instance, if new code relies on changing existing app configuration, developers must review the potential risks with security before committing changes. This will help them avoid several security reviews and other hurdles down the road.

Security Is Now Central to DevOps

Many DevOps teams might have grown accustomed to rapid delivery times at the expense of security, but this picture is changing quickly. Security is now a central component to growing aspects of CI/CD pipelines, and developers must familiarize themselves with this new landscape in order to thrive.

Increase your DevSecOps knowledge by getting certified today at devopsinstitute.com/certifications

An incurable evangelist of cloud security, data protection and cyber risk awareness, Asim Rahal is a Detroit-based independent IT service provider. You can reach Asim via Twitter: https://twitter.com/asimrahal