DevSecOps: Design & Development
What does a secure application actually look like? There are some pretty interesting sources that bring richness to a “secure by design” approach. In the context of DevSecOps, which I introduced in my last blog, design and development of secure apps is a key consideration.
The Rugged Manifesto is something I came across a while ago, which acknowledges that organizations and developers need to put on their “battlesuits” when it comes to releasing software. I love the tone and proactive nature of engineering software with secure practices. According to Rugged Software, being “rugged” is really a cultural movement.
The Rugged Handbook is a great place to start to helping articulate the benefits of taking a “rugged” approach to design and development. Riddled with analogies to various animal kingdom species (muskoxen, honey badgers, and prairie dogs), it is a fun read, but really gets you thinking about the organization aspects of secure software.
When you want to really dig into the specifics of secure development, you can dive into The Rugged Implementation Guide, which discusses specific techniques.
The Open Web Application Security Project (OWASP) has a pretty opinionated stance on security too. OWASP is an open community dedicated to enabling organizations to conceive, develop, acquire, operate, and maintain applications that can be trusted. Design and development is an important foundation, which I mentioned in my previous blog on DevSecOps.
Not beholden to any one vendor or company, OWASP has pulled together its OWASP Secure Coding Practice Quick Reference Guide with 12 prescriptive ways to designing and building secure applications. When you read through these 12 practices, keep in mind that an application should be instrumented with code in alignment with these practices AND be tested with the vulnerabilities that these practices serve to mitigate. Many of these secure practices overlap with the Build to Manage practice from my cohorts in Cloud Service Management and Operations. A good example of this intersection between OWASP and Build to Manage is the “Error handing and logging” practice, which not only brings visibility, traceability, and at times, compliance consideration, but also standardization.
Do you have an InfoSec or ITSec group in your enterprise? Are they brought in at the beginning of a release? Are they providing the delivery squad with assets and artifacts (libraries, coding practices, accelerators) that infuse security you can leverage in your application? If not, this might be an opportunity to collaborate with Security teams and get proactive. Being inclusive and taking a “shift left” approach with ITSec can really build bridges to saving yourself a lot of rework and headaches down the release pipeline. This notion is articulating very nicely in a book I am reading, Accelerate(1), whereby, through measuring continuous delivery in real teams…
(Chapter 6: Integrating InfoSec into the Delivery Lifecycle)
“We found that when teams “shift left” on information security — that is, when they build it into the software delivery process instead of making it a separate phase that happens downstream of the development process — this positively impacts their ability to practice continuous delivery. This, in turn, positively impact delivery performance (…) This can be achieved by ensuring that there are easy-to-consume, preapproved libraries, packages, toolchains, and processes available for developers and IT operations.” (1)
The most important take away with Secure Design is that it should be engineered from the beginning of a product release. Designing and building with secure practices, involving ITSec is critical to successful delivery of secure apps and mitigates the risk of being “blocked” by a security violation surprise.
ITSec should be a willing and enthusiastic participant that contributes to an application and works with Developers.
The “shift-left-onomics” of security falls right in line with the IBM Garage practices of multi-disciplinary, highly collaborative teams that share a product focus. It is a direct assault to the legacy culture of “no” that ITSec is perceived of having. In fact, IBM has some rich guidance in security to safeguard and monitor your cloud apps, which build off of the concepts from the Rugged Software movement and OWASP, which are a bit dated (their last publications were more than 6 years ago).
Be sure to look out for my next blog on DevSecOps: Delivery which addresses security in the release pipeline. And, be sure to check out 2019 DevOps Trends by Chris Lazzaro, :
Bring your plan to the IBM Garage.
Are you ready to learn more about working with the IBM Garage? We’re here to help. Contact us today to schedule time to speak with a Garage expert about your next big idea. Learn about our IBM Garage Method, the design, development and startup communities we work in, and the deep expertise and capabilities we bring to the table.
Schedule a no-charge visit with the IBM Garage.
(1) Forsgren PhD, N., Humble, J., Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations. Portland, Oregon: IT Revolution.
