OWASP CICD-SEC-10, Insufficient Logging and Visibility, is the risk that an attacker operates inside your build and delivery systems without being detected or later reconstructed. The fix is to inventory every CI/CD system, turn on both audit and application logs, centralize them and alert on anomalies in how code ships.
What does OWASP say the risk is?
The OWASP Top 10 CI/CD Security Risks project defines it as risks that allow an adversary to carry out malicious activity in the CI/CD environment without being detected during any phase of the attack kill chain, including identifying the attacker's techniques in a post-incident investigation.
OWASP's observation is that workstations, servers, network devices and key business applications usually get deep logging coverage, while engineering systems and processes often do not. Since many attacks on these systems use programmatic access, tokens and automation, visibility has to cover both human and programmatic access.
Why is the pipeline a blind spot?
Logging is usually off by default in these systems, and nobody owns them as security assets. A source control platform, a build server, an artifact registry and a deployment controller each keep their own logs in their own format, if they keep them at all. An investigator who needs to follow one change from commit to production may have to stitch together five systems, and one of them may have rotated its logs last week.
OWASP is blunt about the stakes: time and data are the most valuable commodities for an organization under attack, and having all relevant data in one location can be the difference between a successful and a devastating outcome.
What does OWASP recommend?
Four steps, in order:
- Map the environment. List every system involved in the delivery path: source control, CI, artifact repositories, package management software, container registries, CD and orchestration engines. Include every instance of self-managed ones such as Jenkins.
- Enable the right log sources. This is not the default state, so it must be done on purpose. Cover both audit logs (user access, user creation, permission changes) and application logs (a push to a repository, build executions, artifact uploads). Give equal weight to each.
- Ship logs to a central place, for example a SIEM, so events from different systems can be aggregated and correlated.
- Create alerts for anomalies within each system and across the code shipping process, which needs knowledge of your own build and deploy flow.
A constructed example
A developer's personal access token is stolen. The attacker uses it to push a small change to a build script on a side branch, triggers a pipeline run that uploads a modified package to the internal registry, and later deletes the branch. Three systems each saw part of this. Source control logged the push and the deletion. The CI server logged a build that nobody on the team recognizes. The registry logged an upload from a service account.
If those logs live in three places with different retention, nobody connects the dots. With them centralized, a single query finds the token, the branch, the build and the artifact in sequence, and a rule that fires when a build uploads to the registry from an unreviewed branch might have caught it live. This example is invented for illustration.
Which events are worth alerting on?
Start with a short list, drawn from the audit and application examples in OWASP's text:
- New users, new tokens or new application integrations created in source control or CI.
- Permission changes, especially to administrator or repository-wide roles.
- Pipeline definition changes and the first run of a changed pipeline.
- Builds that run outside the normal schedule, branch or runner.
- Artifact uploads or deployments that did not come from the expected pipeline.
- Access by programmatic identities from new networks or at unusual times.
How to check or apply this
- Write down every CI/CD system and who owns each. Include forgotten instances.
- For each, check whether audit logging and application logging are enabled, and at what retention.
- Send them to a central store with consistent timestamps and identity fields.
- Pick five alerts from the list above and test each by triggering it in a safe environment.
- Confirm you can trace one change from commit to deployed artifact using logs alone.
- Protect the logs: restrict who can delete them, and keep a copy outside the systems being watched.
- Review the setup after every new tool or integration is added.
Quick check
Is CI/CD logging only about build output?
No. OWASP separates audit logs (who did what to the system) from application logs (builds, pushes, uploads). Both are needed.
Does insufficient logging cause attacks?
No. It lets attacks, whatever their cause, go unnoticed and makes investigation harder. OWASP notes visibility matters for any incident involving CI/CD systems.
Sources
Last reviewed: 18 October 2026.
