DevSecOps

A blog series on DevOps through the lens of security

While I love the satisfaction of securely delivering robust applications, I do not like the term “DevSecOps”.

Photo by John Salvino on Unsplash

DevSecOps is approaching DevOps through the lens of security. In this context, security means engineering secure delivery of robust applications on secure platforms. So, why do I not like DevSecOps as a term? Put simply, when using this term, one might infer that we never considered security in delivery enough in the past, that we need to give it a special term now. NOT TRUE. I believe DevSecOps was coined as a response in the industry around the increasing importance of digital reputations, the proliferation of regulatory compliance, the complexity of cloud native architectures and the rapid changing nature of technology.

First, I want to establish some ground rules and context for this blog series:

• Security is a pervasive consideration through all layers of the solution stack. Network. Hardware. Operating System. Software. Application. Process. Physical location.
• Security should never be an “after thought” to delivery of applications/products
• I will be narrowing the scope of security in relation to design, development and delivery of applications (any broader scope would make for book material)
• When I use the term “applications”, one could conclude that an application is a microservice or a conventional application

First, let’s define what “secure” means in software delivery. In my previous blog “What is DevOps?” I emphasize the fundamental tenants of velocity and quality in application delivery. I view security as a foundation to quality. There are some that view security as it’s own separate tenant…I am good with that too. The point is, security is an integral factor of how a product is designed, delivered and managed. Ultimately, security directly impacts a firm’s digital reputation and brand image. In a world where breaches, unfavorable tweets, and consistently low ratings in an app store can ruin digital reputations of even the largest enterprises, quality and security are increasingly important to the business. When it comes to security in application delivery, we must consider the following:

Is the application designed with a “security-first” mindset?
Is the application delivered with a secure pipeline?

With design and delivery in mind, security considerations fall into 4 main themes:

1. Observability, by ensuring the right people have the appropriate level of visibility into the design, delivery and operation of a product to provide actionable insights to improve security overall.
2. Traceability, by ensuring the ancestry (or provenance) of a Feature is detectable and traceable from inception (user story) through its operational state (production deploy), with significant milestones (commits, builds, scans, test results, deployment, incidents triggered) documented.
3. Risk Mitigation, by ensuring the proper level and amount of testing, scanning, gates, and approvals are in place to mitigate the appropriate amount of risk to deploying a change to a product.
4. Compliance, by understanding what regulations apply to your product (HIPAA, FISMA, PCI, GDPR), impact the way your product must be delivered, and specific activities that must be supported from an audit perspective.

In my next blog, I will address the 4 considerations above in the context of “Secure Design & Development” which addresses secure coding practices and app instrumentation.

Security is one of our 2019 DevOps trends, be sure to check out the full list in this blog by by Chris Lazzaro, here:

2019 DevOps Trends

These are exactly the kind of problems we tackle with clients in the IBM Garage, where DevOps is a fundamental part of how we bring business value to life. Schedule a no-charge visit with the IBM Garage to see how you can co-create with us. Do these ideas and concepts around DevSecOps resonate with you and your firm’s transformation? Let me know with your comments below.