Integrating Aqua with CI CD Pipelines
Integrating Aqua with CI CD pipelines adds container and code checks to your build steps. You set up a scanner step in your runner to inspect images before deployment. Most engineering teams run this scanner right after the container build stage finishes. They give the build runner an API key and a role to send results back. When those runner roles are too broad, any script in the pipeline can misuse them. A compromised build job might change scan rules or read secrets from other projects. How
CI/CD Credential Management + Bitbucket Pipelines Security: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
Integrating Aqua with CI CD pipelines adds container and code checks to your build steps. You set up a scanner step in your runner to inspect images before deployment. Most engineering teams run this scanner right after the container build stage finishes. They give the build runner an API key and a role to send results back. When those runner roles are too broad, any script in the pipeline can misuse them. A compromised build job might change scan rules or read secrets from other projects.
How integrating Aqua with CI CD pipelines works in practice
The native workflow links your source code runner to the Aqua central server. First, a developer pushes code to a repo and triggers a new build job. The pipeline builds a container image or compiles the app packages on a worker node. Next, the pipeline pulls the scanner binary or container image onto that same node. The scanner logs in to the central server using stored credentials from the runner secret store. It reads the local container image layers and checks them against known defect lists. It also checks for hidden keys, bad file settings, and weak base images. Then, the scanner sends a full report back to the central server for logging. The server checks the report against the team policy rules set by security admins. If the image breaks a critical rule, the server returns a fail signal to the runner. The runner stops the build job before the image reaches the registry or cluster. If the image passes all checks, the runner pushes it to the container registry.
Where pipeline scanner roles fall short
This native setup stops bad container images from reaching your production nodes. It gives security teams a clear log of build risks across every project. It also lets teams block known bugs early in the software build cycle. Still, this setup only checks who logs in when the pipeline starts. It does not control what individual commands or requests do during a live session. Build runners often hold static API keys with wide permissions across many projects. If a bad package runs during the build, it can read those stored keys. Also, when a build fails, engineers often need live shell access to fix the issue. They log in to build nodes or databases using shared admin roles to check state. Native scan tools do not inspect the live commands or queries those engineers run. Static role checks happen at login time, not when each command runs in flight.
Securing build runner credentials and human access
To keep pipelines safe, teams must separate build scan permissions from human debug work. Start by giving each pipeline runner a role that only sends scan reports. Do not let the runner role edit central security policies or read other team logs. Rotate the scanner API keys on a set schedule to limit exposure from leaks. Keep the scanner binary updated so it matches the main server version. When a pipeline fails and an engineer must inspect a live database, avoid shared keys. Audit every manual command and query that runs during a build fix session. Mask sensitive fields like emails, phone numbers, card numbers, and national IDs in query outputs. This ensures that fixing a broken pipeline does not expose raw user data.
CI/CD Credential Management + Bitbucket Pipelines Security: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev sits inline in the protocol beside each supported service as an open-source proxy, a sidecar for your database or API. For every query or command an AI agent or engineer runs against production, hoop.dev decides to pass, mask, block, or hold it for human approval.
First, hoop.dev guardrails block banned queries before they run or hold risky ones for review, and hoop.dev data masking rewrites matched sensitive values in responses in memory. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
Where should the Aqua scan step run in a pipeline?
Place the scan step right after the container image build finishes. This checks the exact image before the runner pushes it to a shared registry.
How does the pipeline know when to block a build?
The central server compares the scan report against your active security rules. If the image breaks a rule, the scanner exits with an error code.
How should teams store the scanner credentials in the runner?
Store the scanner login keys inside the secret manager of your CI tool. Never put plain text keys inside your source code files or build scripts.