A Quick Review of Investments Unlimited

The DevOps movement has been trucking along for over half a decade. We are breaking down silos, automating toil, and making life better for the people who create and operate software. As we continue to “shift left,” compliance and security don’t always get invited to the party. This is a problem.

IT Revolution, the folks behind The Phoenix Project and The Unicorn Project, has a new book called Investments Unlimited. Investments Unlimited brings security and compliance into the conversation about DevOps by telling a business fable about a financial company that gets slapped with an MRIA (Matter Requiring Immediate Attention) from government regulators. The book follows the struggle to build new systems that automate compliance and save the company from regulatory doom.

Investments Unlimited is a bit light compared to its predecessors. However, it’s still an important read because it sheds light on how we can bring security into the fold and automate compliance to make the right way the easy way. The book is chock full of valuable concepts, but in their attempt to avoid recommending specific tools, it came up short on implementation details. The book’s main plot revolves around writing a tool that copies the functionality found in many commercially available DevOps tools, which is the real mark of a fable (or at least a “not invented here” culture).

Here are a few essential concepts mentioned in the book:

DevSecOps

DevSecOps adds security to the group of folks called in to shift left. While I’m not too fond of the term creep, I’m 150% in favor of bringing security folks into the early development process, defining security requirements, and then automating compliance via policies and pipeline design.

Golden Path

One of the problems around automating processes in a mature organization is that you always end up with outlying legacy applications that can’t fit into your framework. On the other side is the need to adopt new technologies that might not have widespread adoption in the company yet. Instead of automating all edge cases, focus your efforts on a “golden path” of widely used platforms. If someone needs to go off the golden path, they are in charge of implementing the compliance controls themselves.

The beauty of this approach is that it rewards building on a common platform while not punishing or restricting the ability to innovate. If a team thinks they can do better work with a different stack, they are welcome to try it. Similarly, if an older system is printing money for the organization, it might not be worth re-platforming it.

Software Composition Analysis / Software Bill of Materials

Most modern software is an amalgamation of components. Any given solution can include hundreds of packages (if you doubt this, look at any node_modules folder). These packages can be open source, written by the company, or commercially purchased. A vulnerability in these upstream packages can trickle down to your systems. Tracking these components and ensuring they are secure is a huge task, but several tools can automate the process.

Error / Risk Budgets

Error and risk budgeting is a concept from the SRE community. Instead of defining success as perfection, determine an amount of risk or quality deficit tolerable for your particular application. If your app exceeds its budget (i.e., There are too many risks or quality-related defects), drop everything to remediate the risks and get the application back under the budget. This approach works because it allows you to make appropriate tradeoffs while making plans to improve quality over time.

Should I Read It?

Investments Unlimited is worth a read if you’re interested in a story about how to bring security into the software development conversation. This is an excellent book to listen to while driving to work or mowing the lawn. It’s also a fabulous book to hand out to non-technical folks trying to understand why we care so much about automating everything.

If you’re already doing DevSecOps work, Investments Unlimited is probably going to be too light on details for you. Hopefully, they’ll include more actionable tips in the next version of the DevOps Handbook.