We read an amazing article the other day that states that “Over 30% of Official Images in Docker Hub Contain High Priority Security Vulnerabilities” which if you think about it isn’t really surprising – that fact is probably true for all software just much harder to actually quantify.
Addressing these types of issues is one part of using production assurance to minimize production risk.
The reason that containers is a good way to measure risk is that they have well defined boundaries and each container implements a specific application service, making their separation of concerns easy to understand.
The same separation of concerns is what enables us to quantify the types risks we address through production assurance.
- The first risk for production assurance is the “container risk” for each container used in the application. This entails 2 types – functional risk (bugs in the code) and security risk (vulnerabilities in the code).But boundaries aren’t enough you also need to understand the connections between services. Containers also provides what is needed to understand the service topology as described in the post “Service discovery with Dockers“.
- The second measure of risk for production assurance is “deployment risk” – the risk associated with incorrect configuration or artifact deployment that generates an incorrect service topology.
- The third measure is “COPO risk” (the risk associated with corrective and preventative operations in production). If you have true immutable infrastructure this risk is negligible but deployment risk goes up because there is no “hotfix” only redeployment.
- The fourth risk is “cyber risk” – the risk that an external entities is exploiting your vulnerabilities in your containers and\or services.
These four measures are a framework that provides a process for enabling production assurance feedback loops from Ops to Dev (i.e. the next generation of shift left).