There is an old saying that you can pick only two of the following traits: good, fast, and cheap. If you choose a good and fast path, it will be expensive. If you choose good and cheap, it will take time to get it delivered. Lastly, the fast and cheap selection will yield poor quality.
Over the past decade, companies have embraced DevOps methodologies, and understand the tough selection between the three traits. Tool selection is extremely important to implement a DevOps culture, although it will require more than just the perfect tool.
Successfully implementing DevOps, as a culture and practice, is predicated on automation. Efficient automation is how a company like Etsy does 50 deployments per day. This speed of development and deployment has some obvious advantages—bugs don’t live in production very long because rapid development and deployment replaces them very quickly with corrected code. You can also introduce new features quickly without having to wait for long development cycles to create a complete package. A new feature can be developed and deployed while other features are being developed alongside.
Like DevOps, DevSecOps is a culture. Security-minded companies are often the first to adopt DevSecOps methodologies, where developers work closely with security teams and bring security considerations earlier in the development life cycle — also known as “shifting left.”
In a typical (and simplified) software development process, you might have a requirements phase, followed by design/development, testing, and deployment. Shifting left means introducing security as far to the left in this software process as possible.
The security tools you use are essential to enabling and automating DevSecOps. You need to make sure you are selecting toolsets that will integrate with your existing environment, and support development from the source code repository, through the build process, testing, and deployment. These tools should also be API-enabled so that your developers can leverage them programmatically using automation.
Following are some ways that you could consider introducing security into the development process.
Adding DevSecOps in development processes
Requirements
The best place to introduce security is in the requirements phase. There are significant cost increases to fixing problems in later phases. There may be several ways of addressing
security in the requirements phase but a simple one is threat modeling and ensuring that the identified threats have mitigations in place.
Design/development
The same threats identified in the requirements should be kept in mind during the design and development phase. Designing how the product is going to operate should not introduce new threats while limiting the impact of existing threats that couldn’t be removed. Additionally, developers should always be following secure programming practices that are specific to the language they are using. Additionally, in cases where developers are expected to write test cases, they should be trained to write misuse cases and test against those so their software is more resistant to bad or malformed data being passed through functions they write.
Testing
All requirements should be addressed during testing, but specifically, any threat mitigation identified in the requirements phase should be tested to ensure the mitigation is in place and works. This is a case where misuse and boundaries should be tested. Data should be introduced that would violate the specifications to try to ensure any application failure is safe, meaning it doesn’t present an attacker with the opportunity to manipulate the program space or introduce and run code in a way that violates acceptable risk.
Deployment
The deployment phase may be one of the most critical, especially in the case of web applications or any application that is hosted in a network environment. All systems and containers that are deployed should be hardened, meaning unnecessary software or services should be removed and all access requirements reviewed and tightly controlled. The goal of deployment should always be to limit the attack surface, meaning the ability of an attacker to see any service from either the internet or within the network space controlled by the deployment team. This is also where you implement any changes based on observations from your production environment. Lastly, policy violations that exceed acceptable risk should be addressed before moving anything beyond this point.
Getting started
If you’re in an organization where security and development remain separate until applications are deployed and running in production, adopting a DevSecOps methodology can be challenging, especially when you have well-entrenched development processes. The cultural change alone could be met with resistance by your teams.
It may be easier to slowly push your way backward from the far right. While security testing is a minimum to push to production, you can steadily introduce secure programming practices and threat modeling into your workflows. It’s worth noting that security will typically require specialized staff, and you may not be able to find a single person who understands security from the perspective of all phases, so you’ll be adding additional bodies to your development team.
However, the increased investment in DevSecOps will pay off once you realize that security concerns, especially those that were not addressed earlier in the development process, are one of the driving forces behind deployment delays.
About the author
Ajmal Kohgadai is Principal Product Marketing Manager for Red Hat Advanced Cluster Security for Kubernetes. Prior to its acquisition by Red Hat, he was the Director of Product Marketing and Growth at StackRox, a leading Kubernetes security company.
Browse by channel
Automation
The latest on IT automation that spans tech, teams, and environments
Artificial intelligence
Explore the platforms and partners building a faster path for AI
Cloud services
Get updates on our portfolio of managed cloud services
Security
Explore how we reduce risks across environments and technologies
Edge computing
Updates on the solutions that simplify infrastructure at the edge
Infrastructure
Stay up to date on the world’s leading enterprise Linux platform
Applications
The latest on our solutions to the toughest application challenges
Original shows
Entertaining stories from the makers and leaders in enterprise tech
Products
- Red Hat Enterprise Linux
- Red Hat OpenShift
- Red Hat Ansible Automation Platform
- Cloud services
- See all products
Tools
- Training and certification
- My account
- Customer support
- Developer resources
- Find a partner
- Red Hat Ecosystem Catalog
- Red Hat value calculator
- Documentation
Try, buy, & sell
Communicate
About Red Hat
We’re the world’s leading provider of enterprise open source solutions—including Linux, cloud, container, and Kubernetes. We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.
Select a language
Red Hat legal and privacy links
- About Red Hat
- Jobs
- Events
- Locations
- Contact Red Hat
- Red Hat Blog
- Diversity, equity, and inclusion
- Cool Stuff Store
- Red Hat Summit