Notifications
Clear all
Topic starter
20/08/2026 5:22 pm
TL;DR: March 2026 supply chain incidents involving Trivy, LiteLLM, and Axios show that one compromised workflow can cascade from secret theft to backdoored downstream installs, according to Sonar. The deeper issue is that modern supply chain risk now spans dependencies, CI/CD secrets, and AI coding tools, so security controls have to move into the developer workflow.
NHIMG editorial — based on content published by Sonar: supply chain attacks, secrets exposure, and AI coding tool risk
Questions worth separating out
Q: What breaks when a CI/CD workflow can access secrets from untrusted pull requests?
A: The workflow stops being a safe validation boundary and becomes a secret-exposure path.
Q: Why do supply chain attacks so often turn into identity incidents?
A: Because attackers are not only changing code, they are harvesting the non-human identities that code runs beside.
Q: How do security teams know if dependency controls are actually working?
A: Look for whether build systems prevent unauthorised version drift, whether package provenance is checked before install, and whether secret-handling code is isolated from broad application reach.
Practitioner guidance
- Treat CI/CD runners as privileged identities Inventory every workflow, runner, and deployment bot that can read secrets or publish artefacts.
- Scan for secret exposure before code reaches a commit Run secret detection in the IDE and pre-commit stages, then re-scan in CI to catch anything that bypasses developer controls.
- Gate dependency trust on malicious-package intelligence Distinguish between vulnerable packages and intentionally malicious ones, and fail builds when either category is detected.
What's in the full article
Sonar's full analysis covers the operational detail this post intentionally leaves for the source:
- Workflow-level detection logic for malicious packages, exposed secrets, and CI/CD misconfigurations
- Examples of how pull request findings surface inside the developer workflow and quality gates
- AI coding assistant controls, including hidden instruction file detection and secret leakage prevention
- Cross-boundary SAST and SBOM handling details for teams that need implementation guidance
👉 Read Sonar's analysis of supply chain attacks, secrets exposure, and AI coding risk →
Software supply chain attacks: what IAM and AppSec teams miss?
Explore further
20/08/2026 6:13 pm
Software supply chain trust has become a secrets governance problem. The article shows that attackers do not need to break every control if they can steal one publishing token or pipeline credential. That makes dependency risk inseparable from identity risk, because secrets are the authorisation layer for package publication, CI execution, and cloud access. Programmes that treat supply chain security as pure AppSec are missing the governance model that actually failed.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
A question worth separating out:
Q: Who is accountable when a compromised package or leaked secret causes a downstream incident?
A: Accountability usually spans application security, platform engineering, and the owners of the workflow or release process. If secrets were exposed in CI, the issue is as much a privileged access governance failure as a software defect. Frameworks such as NIST CSF and OWASP NHI help assign control ownership more clearly.
👉 Read our full editorial: Software supply chain attacks are now a secrets problem
