12 Ways to Bake Security Into a DevOps Transformation

Security has become an integral part of any DevOps transformation. According to the Upskilling 2021: Enterprise DevOps Skills Report, DevSecOps achieved a must-have percentage vote of 56% in the automation tool category. Security not only protects the business and its customers, but it enables companies to enforce internal and external policies. 

While considering how to bake security practices into a DevOps transformation, I asked several speakers and sponsors for the upcoming SKILup Day as well as several DevOps Institute Ambassadors to weigh in with their thoughts. Here’s what they shared: 

Sponsor, Kendall Miller, president, Fairwinds

“A DevOps transformation is about building great tooling so that developers can own their services all the way into production. The addition of security is the same thing; it’s building great tooling so that developers can also own the security posture of their services all the way through to production. This transformation is about enabling developers to understand security concerns at the application level. Service ownership is still service ownership—ownership of the operational and security pieces.”

Sponsor, Guy Eisenkot, VP of product, Bridgecrew by Prisma Cloud

“The key to a strong DevOps transformation that keeps security at the forefront is selecting and leveraging tools and processes that lend themselves to automation for your specific stack. For AppSec and cloud security alike, automation is the name of the game. But automation is only as strong as the processes it can fit into and the feedback it provides. 

Security feedback will be futile if it’s not actionable and not given at the right time or in the right place. When undergoing a DevOps transformation, it’s important to keep that in mind when implementing tools and processes. It’s also important that the feedback surfaced is actionable and useful so that engineers can actually learn from and implement secure coding practices.”

Sponsor, Rob Cuddy, global application security evangelist, HCL Software DevOps

“The best place to start is with design and make sure that your epics, stories, hill statements and use cases all have security elements as part of them.  A great idea here is making ‘misuse cases’ or adversarial use cases and then testing against them.  For example–a misuse case might read, ‘As a bad actor, I can use a malformed URL to gain unauthorized access to a web server,’ or ‘As a bad actor, I can impersonate an endpoint in a transaction and both send and receive data while impersonating without the other parties’ knowledge.’

It is also vital to have great SCA–software composition analysis. You cannot secure what you don’t know you have, and this includes open source and third-party tools. In a lot of cases, simple code sharing can inadvertently cause dozens of new dependencies to be added in, and those dependencies can add new vulnerabilities.

It is important to have security aspects tested and validated throughout a pipeline, but particularly at any points in the pipeline where other checks are also being made. A great place to combine this is in QA and wherever functional testing is being done.  Leveraging interactive security testing (IAST) in an environment like this allows for monitoring to occur and for vulnerabilities to be found while application capabilities are being tested.  This greatly reduces the appearance of false positives and provides real-time information about the security posture of applications.”

Sponsor, Yasser Fuentes, cloud workload security technical product manager, Bitdefender

“In short, security should not just be considered at the CI, dev and test phases or limited to vulnerability assessments, since most of the vulnerability scanners and assessment tools DevOps teams use today to go over their CI/CD pipelines rely on either known vulnerabilities, signatures and known attack techniques. As a recommendation, we should emphasize the importance of incorporating tools or solutions which allow developers to identify potential threats and security flaws at the runtime level and which provide visibility beyond the typical anti-malware alerts to suspicious and potentially anomalous process-related behavior.” 

Sponsor, Joni Klippert, co-founder and CEO, StackHawk 

“To bake security practices into a DevOps transformation, teams need to reimagine how security plays in the software development life cycle. For many organizations today, security testing blocks applications from being shipped into production or tries to play catch-up once software is released. But it doesn’t have to be that way. 

Security can (and should) live throughout the pre-production phases of software development. Modern security tools automate security testing in the IDE or CI/CD pipeline, alerting engineers if they have introduced a vulnerability or a vulnerable dependency.

Making security just another type of test that is run in pre-production means teams can find vulnerabilities faster, remediate on the fly and, most importantly, get back to feature development. Baking security into the DevOps pipeline is what all teams should aim for!”

Stephen Walters, sales engineer, Everbridge

“The exact same way that any other practice has become baked in as part of DevOps—by following the CALMS principles. Implementing a culture of inclusion and acceptance; integrating automation into security testing, monitoring, builds and repository management; ensuring the flow and feedback of security into delivery and support is performed in a lean way, adding value and not waste; measuring security as a business value through the use of scorecards and as a success criterion for the business; sharing concerns, lessons learned, new practices and techniques.”

Dheeraj Nayal, global community ambassador & region head – Asia Pacific, Middle East and Africa region, DevOps Institute

“A proactive approach is the best method for building in the essentials of DevSecOps. This can be achieved by following some best practices.

1. Teams should be aligned and in-sync
   The first and foremost step in implementing a DevSecOps culture is to train your teams that security is a shared duty of teams from all three systems. Once development and operations units take on the distributed responsibility of guarding code and infrastructure, DevSecOps becomes a routine part of the development cycle.
2. Keep the code simple
   Complicated code can carry more security vulnerabilities. And simple code is more comfortable to collaborate on. All your developers should be capable of looking at each other’s code and know what is happening.
3. Testing
   SAST (static application security testing) is a key security tool that checks security issues regularly and earlier in the development process which enables it to address the issues more efficiently.
4. Deployment
   To expedite product delivery and add flexibility to the development process, automated deployments are great. One can review properties across the IT infrastructure and implement secure configurations in a system employing an infrastructure-as-code tool. 
5. Operations
   Operations teams must collude with security practitioners. They are accountable for controlling infrastructure and network arrangements. Operations and security teams unite to set up manual and automated security tests to warrant compliance with network configurations.”

Peter Maddison, founder, Xodiac Inc.

“Two main places: within platform engineering to enable the collection of the data you will need for creating visibility, feedback and learning. Next, it is important to engage the security and compliance teams to determine where you can integrate into existing standards or where modifications might be required.”

Mark Peters, technical lead, Novetta

“Security practices can be baked in through the standard DevOps approach, through people, processes or technology. Baking in practices with people means getting folks on the ground with your team who can advocate for security. This can happen through having your security experts spend time with the teams, assigning security to be responsible for teams, or even by selecting champions within those teams who regularly interact with security. The first agile principle, after all, is ‘people over process.’

That component does not allow one to ignore the process.  Building the correct process implies using test-driven development at the start. Every delivery should be tested and those tests should include security testing. Some common security testing, such as code quality, now occurs so frequently many no longer consider it a separate security practice; merely a routine part of development.

Finally, one can bake processes in through technology. Many security tools allow shortcutting through metrics, logs and traces relayed on the dashboard. These tools evaluate and highlight where security challenges occur. Tools allow integration through infrastructure and maintaining awareness of what functions occur and when. One of the old military strategies uses the OODA loop by John Boyd: observe, orient, decide and act. Just as with intelligence systems in the military, better awareness of your system through dashboards allows one to observe functions within the network, orient against possible problems, decide on a solution and act before those problems ever reach critical mass.”

Supratip Banerjee, solutions architect, Principal Global Services

“There are a few ways we can bake security into DevOps:

1. Security as a mindset: There is a thought process that security in the development process might slow it down. But we must educate teams that the time and effort it takes to fix a security flaw early in the process is lower than doing it later.
2. Platforms/environment: Proper configuration/sanitation of deployment platforms/environments is extremely important. Infrastructure-as-code (IaC), configuration-as-code, compliance/policy-as-code, secrets management, etc. can help with the process. Increased use of containers and cloud platforms can keep it clean as underlying infrastructures are managed by the provider.
3. Automation: Include a lot of automation testing in the CI/CD pipeline. Also add static code analysis, third-party testing, AVA testing, code vulnerability checking, container security, intrusion detection and prevention, APM, etc. as automated processes. Make change management, auditing, etc. regular and as self-operating as possible.
4. Secure architecture: Make sure security is enabled at the time of the software architecture/design phase. An architecture risk assessment must be a mandatory process to catch any design vulnerabilities before development starts.
5. Culture of curiosity: Create a culture that emphasizes the importance of security, so everyone is interested and ready to discover if anything goes wrong with security in their system.”

Amiran Alavidze, director of security and risk management, Tasktop

“DevSecOps is about culture and enablement and making software delivery teams autonomous and efficient. Training and awareness is a core component of that enablement. This also includes focusing on tools that are developer-friendly and automated so that critical security controls are an inseparable part of how things are done, and allows development teams to take on all the responsibility, without a cognitive overhead of expert-level understanding of the security domain.”

Sharath Dodda, IT development manager, TD

“By engaging security early in DevOps with as much automation as possible. All the scans that are possible and relevant should be done well in advance in the pipeline, so that the artifact is cleared of all the findings.”

Learn more about DevSecOps and similar topics, by registering for an upcoming SKILup Day. Or, start your upskilling journey by learning more about the benefits of DevOps Institute membership.