Wabi-Sabi Your SecDevOps

Published in

Wabbi

6 min readNov 15, 2019

What is Wabi-Sabi?

Wabi-Sabi is a Japanese philosophy of understanding and embracing the fact that the world is imperfect, never finished, and won’t last forever. It is a concept that can be applied to the everyday, allowing people to appreciate things for the way they are, and not the way they should be.

This is not a foreign concept in today’s software development environments. Think about DevOps, which Jez Humble defines as “ A cross-disciplinary community of practice dedicated to the study of building, evolving and operating rapidly-changing resilient systems at scale .” We accept imperfections in the software we create to allow us to continually move forward and evolve to deliver business value, but why haven’t we modernized Application Security to do the same?

“Wabi-Sabi is an acceptance and appreciation of the impermanent, imperfect, and incomplete nature of everything.” — Beth Kempton

What does Wabi-Sabi have to do with SecDevOps?

Software is inherently impermanent, and even more so with the cloud architectures that allow for CI/CD. Software is never complete: new versions continuously get pushed into production for customers to use. Customers keep wanting new features and capabilities. As anyone who has ever written software knows, it is impossible to write perfect code, there is always a bug to be found, or something to improve upon — it’s why we have technical debt.

Rather than living in a world where trying to develop perfectly secure code becomes the enemy of progress, SecDevOps provides a wabi-sabi point of view on Application Security, aligning AppSec programs with the acceptance that software is impermanent, never complete, and never perfect. This will not only decrease friction in the deployment of AppSec programs, but also improve compliance with them to reduce security risk as it no longer requires a trade-off between agility and security.

To move the traditionally binary world of security — is it secure or not — into development’s continuous evolution, SecDevOps evaluates Application Security in three areas: Context, Complexity, Cost.

Context : What is secure for this application?

Regardless of team size, understanding the software application is vital in having a successful SecDevOps process. Context includes everything from who the end users are and what kind of data will be managed, to the environments your software will be in, and all the tools with which it will interact. This concept already exists in software development in the epics and user stories, where we define the project objectives and details on how to execute. In SecDevOps, these are the specific application security policies that get assigned to the project to build out its security profile.

By understanding the context of the project, the team knows the correct policies to apply as they build the application — whether it’s the PM being able to plan for it in their project schedule, the Architect making the right configuration decisions, or the Developer knowing what the secure coding practices to follow. And these teams are hungry for this information: in fact, 74% of developers want to be involved in developing more secure code.

Questions to ask to understand the context:

How Strategic is this Project?
What is its Visibility?
What are the Availability requirements?
What is the Demand for this system?
What kind of Data does it deal with?
What is the Maturity of the application?

A centralized policy management system will automatically assign the correct policies based on the context which provides confidence to both the Security and Development teams that the right policies are being followed for that specific project.

Complexity: What gets fixed first?

There’s no doubt that software products are complex. Scans, test results, and security policies add in even more complexity. We need to make sure that the output from these scans and test results are processed in a meaningful way to make them understandable and consumable by PMs and Ops to be prioritized correctly. In development, we call this effort estimates — in SecDevOps, they’re security scores.

Without SecDevOps these scores come back only able to talk about how bad they are in the world of vulnerabilities — not for this specific project. And let’s be clear — you cannot evaluate complexity without understanding the context, and while there may be organization-wide policies that must always be followed, each project, asset, and even environment will have different priorities. What needs to get fixed first for a bank’s commercial portal is different than what needs to get fixed first for its trading platform, or even what needs to get fixed for QA to be released is different than for Production.

Questions to ask to understand the complexity:

How critical is this vulnerability to this application?
What is our tolerance for risk on this project?
How hard will it be to fix?
When does it need to be fixed by?

Once results are correctly scored for that project, automated quality gates can be implemented to provide consistent governance and to create actionable workflows. Using SecDevOps to analyze scans and tests will allow your team to get an action plan to bring simplicity into the overwhelming world of security results.

Cost: What is the right amount of risk?

Just like technical debt, there is intentional and unintentional, and short- and long-term security debt — all of which are used to calculate the cost to the business of holding that debt. With application security it is not just the ongoing potential cost of breach risk, but also the required effort that will be required to fix it the longer it persists. Keep in mind cost isn’t just how much you will spend to fix an issue, which can cost 30 to 100 times more to fix on production than during development (NIST), but also the opportunity cost which isn’t limited to security risk, but also features, brand reputation, employee satisfaction, and sales amongst others.

Mindful management of vulnerabilities creates an environment where the team can understand their business impact and prioritize accordingly. PMs can then integrate them into existing workflows which will reduce the upfront cost of non-secure coding practices. Responsible management of vulnerabilities creates a process that can adapt to both ensure safe continuous deployment and adapt to changing and uncertain threats, without driving up the cost of development or reducing productivity.

Questions to ask to understand the cost:

Was this intentional or unintentional?
What was the time to find?
What is the time required to fix?
What is the current threat landscape for our industry, priorities, and company?
What is the business impact?

As “ Largely manual testing efforts create bottlenecks that delay deployments, increase costs (both for testing and remediation) and create frustration for development and security teams alike. “ (Gartner, July 2018), implementing automated governance to manage security debt allows Security & Development teams to focus on strategically managing security debt in line with the business’s risk tolerance.

And like wabi-sabi, it understands that there is no perfect answer. SecDevOps continuously balances security, technical and business risk are balanced to ensure companies keep their focus where it needs to be: on delivering value to their customers and shareholders.

The BIG C: Communication

There’s also a 4th C, communication, which brings the context, complexity, and cost together. At its core, SecDevOps is about improving communication between Sec, Dev and Ops teams. Policies communicate what the risk profile is for that specific application ( context), while scoring communicates the priorities ( complexity), and security debt communicates the future risk ( cost). By bringing all application security information into a single workflow, SecDevOps enables teams to focus on problem solving, rather than triaging.

Successful software applications are built as a team. Team members enable each other with excellent communication; they do not reprimand or scold each other. They review and discuss security at every sprint or meeting. Communication and collaboration allows everyone to take pride in releasing secure software applications.

SecDevOps: Finding Balance

Wabi-sabi is not an excuse for bad security. Instead, it is about taking a practical, informed approach to Application Security that does not try to boil the ocean but manages it as proactively as an integrated part of the development lifecycle. As a development-centric approach, SecDevOps assimilates Application Security processes into Development processes to provide Sec, Dev & Ops teams with just in time actionable information based on the context, complexity and cost for each project.