Managed Docker images and malicious extensions expose IAC secrets

Last week a worrying intrusion was detected in a critical piece of the DevOps ecosystem: the official images of the Docker repository Checkmarx / kics were manipulated by unknown actors. Although the research is still under way, the available information indicates that existing labels were overwritten and that a label was added that does not correspond to any legitimate version distributed by the project. As a result, teams that trusted these images to analyze infrastructure as a code could have exposed sensitive secrets and configurations.

The problem was not just a cosmetic change in the image.: the binary included with the KICS tool was altered to incorporate data collection and exfiltration capabilities. According to the technical analysis that has been made public, the compromised utility was able to create a scanning report that included uncensored data, encryption and sending it to a remote server controlled by the attackers. This makes real risk any file of Terraform, CloudFormation or Kubernetes manifests containing credentials or sensitive variables that have been passed through that manipulated version.

In addition, the investigation has found evidence that the impact could be extended to other official distribution channels of the same manufacturer. Concrete versions of an extension of Microsoft Visual Studio Code that incorporated malicious behavior have been noted: they downloaded and run remote code through the runtime Bun using a URL set on the code, without asking the user for confirmation or verifying the integrity of the downloaded content. This reinforces the hypothesis that it is not a single committed image, but a broader campaign against the supply chain.

What should the organizations concerned assume? In practical terms, any secret that has been through these scans should be considered possibly compromised. The exfiltration of analysis reports with unfiltered data means that temporary credentials, service keys or environment variables used in IAC templates could be in the hands of attackers. Therefore, immediate and priority action is to assume the worst possible possibility and act accordingly.

The urgent measures to be taken include stopping the use of suspicious images and reviewing pipelines and records in search of abnormal activity, rotating credentials and secrets that may have been exposed, and conducting a forensic assessment of the systems that executed such images or affected extensions. It is also recommended to reestablish images and binaries from verified sources and, where possible, to validate signatures or checksums before deployment.

If you are looking for resources and good practices to handle this type of incident and to strengthen the defence against handling in the supply chain, there are documentation and public reference guides. Bodies such as the US Infrastructure and Cybersecurity Agency. United States (CISA) collect notices and recommendations on supply chain commitments ( https: / / www.cisa.gov), and projects such as SLSA provide a framework for strengthening the integrity of artifacts and construction processes ( https: / / slsa.dev). GitHub also maintains resources on how to protect software supply flows ( GitHub supply chain security guide).

At the practical level of the day-to-day, it is appropriate to check which exact versions were used in the CI / CD environments, to check network logs for outgoing transfers from the scanning work, and to audit IDE extensions installed in workstations and construction agents. If extensions are identified with suspicious behavior, it is wise to remove those extensions and restore environments from known and verified states. To reduce future risk, the adoption of signed images, unchecked external unit blocking policies and more restrictive access controls in pipelines help to mitigate the possibility of a single committed image becoming a larger gap.

The incident also raises a broader reflection on the confidence we place in third-party artifacts. Tools that run with permissions to inspect infrastructure and configurations deserve special treatment because, by their own function, they can process secrets. Implement practices such as local scanning with verified binaries, the use of isolated environments (sandboxing) for automated analysis and the segmentation of credentials in test environments can reduce the impact if a tool is compromised.

Finally, it is important to follow the official communications of the supplier and the image registrers. In such cases, maintenance and repositories often file or remove committed devices and issue recovery instructions. It is also appropriate to be kept informed through specialized means and security notices to know the affected versions, the published corrections and the commitment indicators (IOCs) that allow the search for traces in the systems. You can check the site of the affected repository in Docker Hub for the status of the repository https: / / hub.docker.com / r / checkmarx / kics and consult the official website of the supplier for communications or patches https: / / checkmarci.com.

This type of incident recalls that modern security depends not only on a specific tool, but on how the entire chain that carries an artifact from the developer to the production is administered. Rotate secrets, verify the source of images and binaries, and maintain an updated incident response plan they are no longer good practices to become operational obligations if we want to minimize damage when something fails in the supply chain.

If you want, I can help you to write a list of specific controls to apply to your CI / CD pipeline, or to prepare a technical message for your team by explaining the immediate steps to follow and how to look for signs of engagement in log and repository.