At Bridgecrew, we’ve seen our customers benefit from maintaining a GitOps mentality. By making all changes in infrastructure as code (IaC) and pushing those changes through a secure development pipeline, they can enforce proactive security guardrails to prevent code misconfigurations from snowballing into a litany of runtime alerts. However, when issues do appear in runtime, we know how tempting it can be to solve the issue then and there, rather than hunting down the code and/or the developer owner to do it right.
Let’s take an example. Let’s say that a security engineer views the Incidents page and notices a misconfiguration: an S3 bucket created by a Terraform file is encrypted with an AWS-owned key, but the company’s policy is to use a company-managed key (CMK). The easy solution would be to log into the AWS console and switch the encryption key to a company-managed CMK. However, if terraform apply is run, the encryption will go back to the previous configuration. Worse, if someone copies that file to start their next project, they will be automatically starting out with a policy violation.
This is why we heavily emphasize the importance of traceability between code to cloud and vice versa in our platform. Only with proper traceability can runtime resources be tied back to the IaC resource block that provisioned them and the developer who last modified the code.
We’ve simplified the process by leveraging our open-source tool Yor to automate the addition of trace tags in build-time, and our platform extends this functionality to improve the process of remediating runtime alerts.
Tracing on the Resource Inventory page
Let’s start with the Resource Inventory screen. Adding a filter that looks for the yor_trace tag will surface all the traced resources. These are all of the IaC resource blocks that were tagged using either Yor or the Tagging Bot powered by Yor.
Selecting “Explore code resource” lets you toggle between the metadata for both the code and the cloud resource and provides a complete inventory of all assets traced from code to cloud.
Tracing on the Incidents page
Our newly redesigned Incidents page includes many features that help trace incidents identified in the cloud to code. Beginning with the new filters, you can easily find the runtime incidents within assets that are traced in code. This allows you to switch between the metadata for both the runtime and code resource so you can see the details of both the running asset and the code that provisioned it.
From there, selecting “View in Projects” takes you directly to the corresponding policy violation in code on the Projects page.
Traceability also comes into play for detecting cloud drift— modifications done directly to the cloud instead of the code. If both code and cloud resources include the trace tag, Bridgecrew will surface drift alongside other misconfigurations.
Tracing on the Projects page
Tracing shows up in a few places on the Projects page, depending on how you were routed. If you get routed to the Projects page from the Incidents page, the Projects page will automatically be filtered down to just the same violation in code.
With the violation finding, you can see the file, line of code, and last editor, with a link to the repository, so you can reach out to the right developer to find and fix the issue in code. They have the most context for the code, so they should be able to address the issue quickly. Additionally, we let developers know when their code misconfiguration is impacting a runtime resource, so they know that it is a higher priority to fix that issue.
Drift will also be surfaced in the Projects page with the ability to fix the drift by creating a pull request to add the cloud changes back to the code repository automatically.
The importance of traceability in cloud security
Let’s go back to the example of our S3 bucket. The security engineer may spot that incorrectly encrypted bucket in runtime and go to the violation in the Incidents page. Then, seeing the traced icon, they can be transported to the code where the actual fix should occur. If, instead, that person fixes the issue in the cloud console, Bridgecrew will surface the drift and can even help remediate it in code via a fix pull request.
Once the security engineer has traced the runtime issue to the right code block, they can leverage git blame data and metadata to inform the right person about the exact issue (e.g. switching bucket x with from file y.tf on line z to CMK encryption) with all of the context they need to get it fixed right away.
All of these features tie back to one primary goal—find issues anywhere, but fix them in code faster.
The traceability features we’ve built into Bridgecrew address that from multiple angles. If an issue is found in runtime, it can be easily traced back to code and remediated. If it’s remediated in the cloud, Bridgecrew will detect the drift and help you bring the code back in line with the runtime environment.
Try out our traceability and other cloud-to-code security features with our 14-day trial!
