Trends, Tools and Best Practices – InApps 2022

DevSecOps is the culture and practice of making security part of the entire software delivery process from start to finish — a discipline increasingly associated with overall resilience and DevOps best practices.

The people who pioneered DevOps were optimizing for deployment velocity. They had to focus on configuring the hardware to fit the software architectures. Until the recent Site Reliability Engineering (SRE) movement, resilience has not been a traditional DevOps metric, just as security was not a traditional DevOps metric until the move towards DevSecOps. DevOps as a cultural movement focused on efficiencies, velocity, feature development and continuous development. SRE is focused on resiliency and the ability to handle spikes in usage or disruptions in cloud provider service without outages or performance hits.

Traditionally, security has sat on the outside, isolated in culture, organization and workflow from development teams, operations teams, DevOps teams and SRE teams. The teams have dealt with different success metrics and different performance indicators. Yet there is a clear overlap between DevOps, SRE and security, as Application Programming Interface (API) endpoints become more vulnerable and required better risk management. This brings us to the new world of DevSecOps.

Modern architectures are forcing deeper integration between DevOps and SRE teams. And the same forced integration is extending to security teams. This is DevSecOps.

Programmatic infrastructure, also known as Infrastructure-as-Code, binds them together. It provides automation, metrics and analysis to continually develop DevOps, SRE and DevSecOps practices. Metrics overlap across all three disciplines. Customer tickets, for example, are a metric in DevOps. In DevSecOps, customer support security tickets are a metric. There is a mutual interest in decreasing the number of bugs and vulnerabilities across the different disciplines.

For example, vulnerabilities may be decreased by automatically separating the ones that are not loaded into memory and thus don’t need to be fixed. Automated vulnerability detection is just one example of how anomalies may be more easily discovered, making the overall infrastructure more resilient to attacks.

Continuous development teams now have to focus on the principles of integrating security from the very start. In terms of resilience, scale-out architectures must consider services as cells that have their own layers of protection but are still connected in loosely coupled environments.

In our first “Best of InApps” anthology, we’ve picked six of our top posts from the past year, authored by InApps and our contributors, and paired it with our own analysis to provide deeper perspectives about DevSecOps and the trends emerging around it.  The result is a quick read to get you up to speed on the latest thinking in DevOps and cloud native security trends. In The Best Of DevSecOps: Trends in Cloud Native Security Practices ebook you’ll find:

• The primary and secondary impacts of DevSecOps.
• Reasons to shift security both left and right.
• Why velocity equals automation.
• How declarative environments are suited for DevSecOps.
• Why treating security holistically allows for better resilience.

So what goes into resilience and reliability when we discuss at-scale application development, deployment and management? And how does it apply to DevSecOps? Observability and chaos engineering come to mind. Both approaches help organizations make their services more resilient and reliable.

Chaos engineering is a concept pioneered by the Netflix Edge tools team. The idea: unleash the chaos monkeys to create havoc for testing the system and in the process, make it more resilient. Observability allows the SRE to find the “unknown unknowns” that uncover issues such as latency problems. Security teams also require ways to separate the signal from the noise as older practices, such as monitoring, which are really meant for legacy architectures, persist. Cloud native architectures, with their container-centric approach, require a different, more sophisticated way to view across distributed environments, including automated security feedback loops.

Security and resiliency are often interrelated, but the relationship is rarely discussed. Ask even accomplished technologists about security and they will say that security and the software development life cycle (SDLC) are completely separate. More than one engineering executive has made this remark to InApps in recent conversations.

DevSecOps has become a necessity as connected container-based architectures depend upon the sharing of data. Each service is integrated into the larger service. Communication in its old-fashioned human form is as essential as automated communications between services.

The more security is built into the SDLC, the more confidence the organization has in its security posture, according to the 2019 State of DevOps Report. And remediation is faster when security is integrated, according to the 2020 State of DevOps Report. Some 45% of organizations that had integrated security into all phases of the SDLC said they could remediate a critical vulnerability within 24 hours, while only 25% of organizations with no integration could do so.

Still, the confusion over how best to integrate security into the SDLC continues, as well as which security tools to use, even among companies with mature DevOps processes. Many practitioners are unsure if they should depend on their cloud service for tools, use third-party tools, roll their own, or depend primarily on open source security tools.

Maybe a better way to think about DevSecOps is from the point of view of making security a routine part of an engineer’s job. Integrating security into an ordinary development workflow has its challenges but it’s a lot better than dealing with crises. An ordinary life is the best life. But achieving an ordinary, crisis-free life requires a lot of work. It means keeping with routines, establishing behavioral best practices and controlling what you can control.

It’s a state of tension and anxiety, knowing that security can’t be hammered into software development as a last step. That is perhaps how it used to be when tightly coupled architectures were configured, taken down for days and often weeks to be prepared for a new version of the system of record.

In reality, the future is right in front of us and so is the path to true resilience. Container-based architectures are resilient by design. Immutable infrastructure allows for containers to be deleted and replaced with new ones. That’s a welcome change from older approaches that did not have that ease of replacement. Programmable security and the accompanying DevOps practices are the next steps on this path.

DevSecOps may not be as complex as we make it out to be. It’s there already in the form of modern architectures. Now it’s just a matter of defining the orchestration itself to automate and scale security practices in environments already resilient by design.