It seems obvious to say, but without context, nothing for us as humans makes any sense.
I have recently started learning Russian. I was very proud of myself for learning the block letters of the Cyrillic alphabet when I then learned that there is also the cursive letter set, in which several of them just seem like an endless series of pointed lines.
My teacher gave the dubious explanation that Russians have the context and expectations of seeing such words in context and therefore can easily read them. I am still not so sure about that, but context is essential for an accurate understanding of pretty much anything. Without enough context, understanding and insight is hard to achieve, and worse, lack of context can often lead us to the wrong conclusion.
So what does this have to do with continuous integration security?
Our business is to deliver “checks as a service”—checks of cloud object configurations, endpoint state, and application state. The problem is that without a lot of context, it is almost impossible to effectively manage these types of objects at scale. For example, if I have no idea that a set of objects are part of application X, I cannot perform application-specific checks, which are the very checks that are most likely to ensure that the application is available, performant, and secure.
Taking this idea further, if I don’t understand the build context (which Jenkins job, which repositories, which code deltas triggered the build), I can’t understand which objects I am referencing from an earlier stage, or another build, and I can’t tell the difference between those objects and new objects created for the current build. I can’t understand the relationships between producers and consumers.
So if we consider the opposite, if I can understand which objects are part of which builds, and which are not, I can start to assess which “parts” of my cloud account are under active management (under certain process controls and governance), and which parts were constructed under ad-hoc tooling and processes. When you can begin to clearly identify the ad hoc pieces, you can begin to manage them and bring them under the same processes and governance as the automated parts of your cloud.
The result is far better context which allows better filtering (less to look at) and follow up (for example, knowing when remediation can happen). Let’s say a check is for too open S3 bucket permissions. Simply detecting this is good, but without the full context, this violation will often be one of thousands, and it will be unclear who set the permissions, whether it should be remediated, or if it is safe to remediate.
One of the difficulties with the way issues are currently tracked, is that it’s often done with “over the top” scanning, where the security team is given a tool to scan an entire cloud account, and the result is an enormous list of violations. By looking at an entire cloud account, security loses the most critical context—what is the object for, and what role is it supposed to play. To get that critical context, you need to look at cloud objects in the same way they are built—in the context of the application.
The most context in our domain is the context where a code change has been checked in, and that code needs to be changed in order for the application to remain secure. Catching such changes at the time of the check-in and initial pipeline build allows applications to be delivered secure from the start.