Ever heard about DevSecFinBizOps?

Since DevOps has grown into a successful set of principles for agile teams, the trend around other “Ops” derivatives keeps piling up. If you listen to the various discussions in IT professions, you probably stumbled upon BizOps as the business extension of DevOps, or SysOps for system administrators and even FinOps, related to billing accountability during software development. All in one, it seems like a single team can now own all these dimensions at once, hence the patchwork-esque incantation of “DevSecFinBizOps”.

Today, let’s cool things down and focus on only one critical silo, yet often processed as an afterthought: security. Security, on the own admission of developers, is best expressed as code itself, rather than outsourced to another team, or God forbid, stored in documentation.

In this blog post, we review the current state-of-the-art for security as code, and how much is already available in Artifakt PaaS.

3 main principles of DevSecOps: start from here

As experts agree, the three pillars of DevOps are:

1. Continuous integration and delivery

2. Automation

3. Culture

Although security is not part of the original definition of DevOps, it is an important pillar of DevSecOps. To be successful, a DevSecOps strategy must take into account the following three features:

1. No manual patches, no fragmented documentation

2. Code-first security

3. Security as code

When you think of the word “security”, what comes to mind? Usually, it is some sort of defense mechanism or protection against a breach. In the DevOps world, however, the term seems a bit more nebulous.

Many organizations have implemented tools that allow security to be seamlessly integrated into their workflows but this is not enough. The real question is: how can they make sure they are secure while pushing new features?

The DevOps model has changed how IT organizations deliver software. The security organization must keep pace with the rest of DevOps and change how it is delivering security. We need to pivot from a manual, tool-centric, project-based approach to a more automated, code-first approach that allows us to scale with the rest of the organization.

The idea of hardening an environment has been around for decades. However, most traditional approaches require manual patches and fragmented documentation that doesn’t scale across multiple environments. In contrast, a code-first security approach helps ensure that only hardened configurations are allowed into production environments.

Implement DevSecOps with Infrastructure as Code

Here are a few key practices that define DevSecOps:

1. Shared responsibility for security. Security is the responsibility of everyone involved in an application’s lifecycle, including developers, operations engineers, and managers. Even business owners are responsible for assuring that an application is secure to use by end-users.
2. Security automation throughout the build pipeline. Security has traditionally been left until later in a project’s life cycle because it can be time-consuming if done manually. But with automation, developers can integrate security checks into automated tests that run as part of the build pipeline when code is checked in.
3. Security testing with infrastructure as code (IaC). Infrastructure as code lets you describe your infrastructure configuration using dedicated languages or frameworks.

The keyword here is “shift-left”, i.e the practice for security issues to be detected, analyzed and addressed as early as possible in the development process.

JFrog found that the cost to U.S. companies in 2020 of what the Consortium for Information & Software Quality (CISQ) calls “poor software quality” goes above $2 trillion. Cost came from operational software failure, estimated at $1.56 trillion, which is caused primarily by unmitigated flaws, mostly unpatched known vulnerabilities.

This is where DevSecOps comes in. DevSecOps helps organizations ensure that security is built in throughout the entire delivery pipeline — from development through production, and everything in between — so that no one on the team ever has to ask, “Where does security fit in?”

Leverage GitOps to pilot infrastructure changes and build a track record

To create a DevSecOps culture, you have to provide tools that work within the development lifecycle. You need to demonstrate that it won’t require more effort for developers to convince them to use security tools.

This is where GitOps comes in. It provides auditability and reproducibility of changes, where everything can be tracked from a single source of truth in git. For example, you can track configuration changes for tightening network configurations in your infrastructure with Kubernetes resources. This process allows for easy rollbacks and is great for general management and deployment of environments that you manage with Kubernetes.

However, we still want to make sure that the security engineer has a say in the process. So we make sure that there are some basic tests the application needs to go through before it is deployed.

We also check the code for bugs and vulnerabilities, just like any other team would. We do this by running common tools such as static analysis software against the codebase. It’s important to run these checks early in the development process so that if an issue is detected, it can be addressed before too much progress has been made on a particular feature branch.

The whole process should lead to a software bill of materials (SBOM), describing all components and their versions at one point in time. 

Production is the blind spot of developers, where software dies in silence.

But production does not live a quiet life either, you see software, like apples in the sun, is quickly rotting and losing freshness.

As much as the shift left principle enforces security in early stages before deployment, developers need to make sure the container images, their host operating system and all libraries running inside stay up-to-date from newly discovered vulnerabilities that would occur after the deployment.

You can successfully deploy today, and let the application happily live for weeks because no features were planned, and no bugs were filed. Wrong! The production systems must be continuously scanned, as well as sources of truth like the container registry. If any vulnerabilities are found, an issue can be generated for the team, and an ensuing build will block any attack based on what scanning just discovered.

This is easily tracked in cloud systems with the age metric. Contrary to popular culture of uptime competition and endlessly running servers, the fresher the server the better. This has been detailed by Docker Security Team Lead Diogo Monica, back in 2017, where he coined the metrics of “reverse uptime” and “golden image freshness”.

At Artifakt, we take security seriously from the moment you connect your code, to the live code in production, and scanning it is part of our expertise. That’s another reason to let us handle the grunt work and focus on your business.

Last word, cloud account is the ultimate security isolation

On the public cloud as well as other systems, security is a matter of layers. On one side, we have old school advocates of the Citadel Myth. They think that one great firewall around their infrastructure is enough to protect them from intrusions.

On the other hand, the Zero-Trust pattern pushes the paranoid mode to the extreme. Not only the application next to yours is a possible vector attack by default, but Zero-Trust  also takes inner components like databases or file systems as a source of potential threat. 

As an avid cloud user, Artifakt learned to protect our customers by applying the ultimate isolation between resources: the cloud account itself. Even if you apply firewalls, security groups, VPCs and other network abstractions, it still does not beat the cloud account level of isolation. 

Conclusion

Before parting away, we’d like to close on an essential ingredient. Successful DevSecOps strategies share similarities with DevOps in the sense that they are an iterative process. Teams learn as they fail, or deliver security as they go. It’s as much a 0-day decision, as it’s an ever going process. In other words, start on the first day, then measure feedback, and make small steps toward security as code.

With this simple workflow, teams build a culture of security by design, by ultimately approaching vulnerabilities as defects to fix like any other bug. Artifakt PaaS sure gives a good jumpstart in the right direction of DevSecOps, but we would love to hear from you about other ways you explored the subject! Feel free to reach out and comment.