← Back to Cybersecurity News Center
Severity
CRITICAL
CVSS
9.5
Priority
0.850
Executive Summary
A threat actor tracked as TeamPCP by SANS ISC and UNC6780 by Google GTIG has exploited the Trivy open-source security scanner to compromise CI/CD pipelines, resulting in confirmed Cisco source code theft. The campaign is actively tracked in SANS ISC reporting, inverts a core DevSecOps assumption: that security tooling itself is trustworthy. Defenders should prioritize audit of scanner credentials and pipeline permissions immediately.
Technical Analysis
The TeamPCP campaign represents a deliberate targeting of the security toolchain itself.
Trivy, an open-source vulnerability scanner widely deployed in Kubernetes and container CI/CD environments, served as the attack vector rather than the defense.
This is a meaningful tactical evolution: attackers are now mapping the tooling organizations trust implicitly and weaponizing it.
Security scanners typically run with elevated access to container registries, source code repositories, and secrets stores. Compromising the scanner means compromising everything the scanner can reach. The specific mechanism by which Trivy was exploited has not been fully disclosed in available public reporting as of this analysis; organizations should monitor the SANS ISC Diary for technical indicator updates.
Cisco source code theft is the highest-confidence confirmed impact in available reporting. Supply chain theft of vendor source code carries second-order risk beyond the immediate victim: if adversaries analyze Cisco source code for previously unknown vulnerabilities, downstream customers across enterprise networking and security infrastructure become potential future targets. Google GTIG's formal tracking of this group as UNC6780 signals that the campaign has met the evidentiary threshold for a distinct threat actor designation, a meaningful indicator of campaign scale and sophistication.
The CI/CD pipeline compromise angle is technically significant. Pipelines often inherit secrets, tokens, and credentials scoped broadly for automation purposes. An attacker who can inject into or manipulate a pipeline stage, particularly one involving a security scanning tool, gains access to artifacts, registries, and potentially signing keys without triggering conventional endpoint or network detections. Organizations running Trivy in automated pipelines should treat any Trivy execution environment as a potential lateral movement surface and audit what credentials and registries it can access.
One structural gap in current reporting is the absence of specific CVE identifiers tied to the Trivy exploitation mechanism. The campaign is confirmed and actively tracked, but the precise vulnerability class used to weaponize Trivy has not been publicly disclosed. This limits the ability to write precise detection rules or apply targeted patches. Until CVEs are published, defenders should focus on behavioral controls: monitoring for anomalous Trivy process behavior, auditing CI/CD pipeline permissions, rotating credentials accessible to scanner tooling, and reviewing pipeline logs for unexpected network connections or artifact access patterns.
Action Checklist IR ENRICHED
Triage Priority:
IMMEDIATE
Escalate to CISO and legal/privacy counsel immediately if any Trivy instance is confirmed to have executed with access to source code repositories, container image signing keys, cloud provider credentials, or secrets management systems (HashiCorp Vault, AWS Secrets Manager), as this constitutes a confirmed supply chain compromise with potential for downstream customer impact and regulatory breach notification obligations under GDPR, CCPA, or sector-specific frameworks.
Audit Trivy deployment permissions immediately: determine what credentials, registries, and repositories your Trivy instances can access, and apply least-privilege scoping. Scanner tools do not need write access or broad secret access to function.
Containment
NIST 800-61r3 §3.3 — Containment Strategy: Restrict scope of compromise by limiting attacker-accessible resources before full eradication is complete
NIST IR-4 (Incident Handling)
NIST AC-6 (Least Privilege) — enforce minimum necessary access for Trivy service accounts and pipeline tokens
NIST CM-7 (Least Functionality) — disable Trivy access to secret stores, container registries, and source repos beyond scan targets
CIS 5.4 (Restrict Administrator Privileges to Dedicated Administrator Accounts)
CIS 6.1 (Establish an Access Granting Process)
Compensating Control
Run: `grep -rE '(TRIVY|trivy)' ~/.docker/config.json /etc/environment /home/*/.bashrc /home/*/.profile /etc/profile.d/* 2>/dev/null` to enumerate credential exposure. On Kubernetes: `kubectl get serviceaccounts -A | grep -i trivy` then `kubectl describe serviceaccount <sa-name> -n <ns>` to enumerate bound RBAC roles. Immediately revoke any Trivy service account tokens with `kubectl delete secret <token-secret>` and reissue scoped-down replacements. For GitHub Actions/GitLab CI: audit `GITHUB_TOKEN` permissions in workflow YAML files for `contents: write` or `packages: write` scopes that Trivy jobs should not require.
Preserve Evidence
BEFORE revoking credentials, capture the full permission scope: export `kubectl auth can-i --list --as=system:serviceaccount:<ns>:<sa>` output for each Trivy service account. Snapshot CI/CD environment variable configurations (GitHub Actions secrets list, GitLab CI/CD variables, Jenkins credentials store) to document what secrets were accessible to the Trivy execution context. Preserve container image digests of Trivy versions currently deployed — UNC6780 weaponized the scanner binary itself, so the running image hash is critical forensic evidence of whether a tampered version was in use.
Treat CI/CD pipeline stages running security tooling as high-value lateral movement targets: review pipeline logs for anomalous process execution, unexpected outbound connections, or access to artifacts outside normal scan scope.
Detection & Analysis
NIST 800-61r3 §3.2 — Detection and Analysis: Correlate pipeline telemetry to distinguish legitimate scanner behavior from UNC6780 lateral movement through the DevSecOps toolchain
NIST IR-5 (Incident Monitoring)
NIST AU-6 (Audit Record Review, Analysis, and Reporting)
NIST SI-4 (System Monitoring)
CIS 8.2 (Collect Audit Logs)
CIS 7.1 (Establish and Maintain a Vulnerability Management Process)
Compensating Control
On pipeline runner hosts (GitHub Actions self-hosted, GitLab Runner, Jenkins agent), deploy Sysmon with the SwiftOnSecurity config and specifically enable Event ID 1 (Process Create), Event ID 3 (Network Connect), and Event ID 11 (File Create). Query for: `Get-WinEvent -LogName 'Microsoft-Windows-Sysmon/Operational' | Where-Object {$_.Id -eq 3 -and $_.Message -match 'trivy'}` to surface outbound connections initiated by Trivy processes. For Linux runners, use `auditd` with rule: `-a always,exit -F exe=/usr/local/bin/trivy -S connect -k trivy_outbound` and review `/var/log/audit/audit.log` for unexpected destination IPs. Cross-reference Trivy process network destinations against the SANS ISC Diary IOC list for UNC6780 C2 infrastructure.
Preserve Evidence
Capture pipeline execution logs for all Trivy job runs in the 90 days preceding detection — specifically the stdout/stderr of Trivy scan invocations, which may reveal unexpected flags, targets, or output destinations injected by UNC6780. Collect runner host process trees: on Linux `ps auxf` snapshots or `/proc/[pid]/cmdline` for Trivy PIDs. Preserve network flow logs (VPC flow logs, NetFlow, or `ss -tnp` snapshots) from runner hosts showing all outbound connections made during Trivy execution windows. For containerized runners, export Docker daemon logs (`journalctl -u docker`) and any `docker inspect` output for the Trivy container showing mounted volumes and environment variables.
If your organization uses Cisco networking or security products, monitor Cisco's security advisories and PSIRT disclosures for new CVEs. Source code theft is often a precursor to novel vulnerability discovery targeting downstream customers.
Post-Incident
NIST 800-61r3 §4 — Post-Incident Activity: Intelligence sharing and threat-informed posture improvement following confirmed source code exfiltration by UNC6780
NIST SI-5 (Security Alerts, Advisories, and Directives)
NIST RA-3 (Risk Assessment) — reassess risk posture for Cisco-dependent systems given confirmed source code exposure
NIST IR-8 (Incident Response Plan) — update IR plan to include monitoring cadence for Cisco PSIRT as a standing post-incident action
CIS 7.1 (Establish and Maintain a Vulnerability Management Process)
CIS 7.2 (Establish and Maintain a Remediation Process)
Compensating Control
Subscribe to Cisco PSIRT RSS feed at `https://tools.cisco.com/security/center/psirtrss20/CiscoSecurityAdvisory.xml` and pipe new entries into a local alerting script: `curl -s <feed_url> | python3 -c "import sys,xml.etree.ElementTree as ET; [print(i.find('title').text) for i in ET.parse(sys.stdin).findall('.//{*}item')]"`. Set a weekly cron job to diff the advisory list and alert on new critical/high entries. For Cisco IOS/IOS-XE: run `show version` and `show inventory` across your fleet and map installed versions to the Cisco Software Checker tool to pre-identify exposure when novel CVEs emerge from the stolen source code.
Preserve Evidence
Document current Cisco product and version inventory (IOS, IOS-XE, NX-OS, ASA, FTD, ISE version strings) NOW as a pre-exposure baseline — this becomes the reference point for rapid impact assessment when UNC6780-derived CVEs surface. Preserve Cisco device configuration exports (`show running-config` or Cisco DNA Center exports) to support rapid diff analysis if a post-source-code-theft vulnerability targets specific configuration patterns. Archive the current Cisco PSIRT advisory index as a dated snapshot to measure new advisory velocity — an unusual spike in Cisco CVEs in coming months is a direct indicator of weaponized source code use.
Cross-reference IOCs from the SANS ISC Diary against your SIEM and EDR telemetry: the campaign is confirmed active and indicators should be treated as live, not historical.
Detection & Analysis
NIST 800-61r3 §3.2 — Detection and Analysis: Prioritize IOC matching against live telemetry given confirmed active campaign status; treat UNC6780 indicators as current threat intelligence, not archived artifacts
NIST IR-4 (Incident Handling)
NIST AU-6 (Audit Record Review, Analysis, and Reporting)
NIST SI-4 (System Monitoring)
CIS 8.2 (Collect Audit Logs)
Compensating Control
Extract IP, domain, hash, and URI IOCs from the SANS ISC Diary entries for TeamPCP/UNC6780 and operationalize them immediately without a SIEM: (1) Hash IOCs — run `find / -type f -exec md5sum {} \; 2>/dev/null | grep -Ff ioc_hashes.txt` or use `yara -r teamPCP_rules.yar /path/to/scan`; (2) Network IOCs — query DNS resolver logs with `grep -Ff ioc_domains.txt /var/log/named/queries.log` or pfSense/OPNsense firewall logs; (3) IP IOCs — `grep -Ff ioc_ips.txt /var/log/ufw.log` or equivalent host firewall log; (4) For pipeline-specific IOCs, search GitHub Actions workflow run logs and GitLab CI job traces using the IOC list as search strings. Write Sigma rules targeting Trivy process ancestry and outbound connection patterns for use with `sigma convert` against local log files.
Preserve Evidence
Before bulk IOC sweeping, preserve unmodified copies of all CI/CD pipeline job logs, runner host syslogs, and network flow data covering the 90 days prior to April 8, 2026 — this is the confirmed active window. Capture DNS query logs from your resolver for all domains resolved by pipeline runner hosts, as UNC6780 C2 communication from weaponized Trivy would appear here. Preserve EDR process execution telemetry or Sysmon Event ID 1 logs for Trivy binary executions, including full command-line arguments and parent process context, as IOC matching against these may reveal the specific campaign variant active in your environment.
Document use of SANS ISC and Google GTIG reporting as your authoritative source where CISA guidance is not available. This protects your audit posture in compliance review.
Post-Incident
NIST 800-61r3 §4 — Post-Incident Activity: Maintain defensible documentation of intelligence sourcing and compliance decision rationale when primary regulatory guidance (CISA KEV advisory) is absent
NIST IR-6 (Incident Reporting) — document the gap between KEV deadline and CISA advisory issuance as part of incident record
NIST IR-8 (Incident Response Plan) — update IR plan to codify fallback authority hierarchy when CISA advisory is absent
NIST AU-10 (Non-Repudiation) — maintain irrefutable records of intelligence source citations and compliance actions taken
NIST AU-11 (Audit Record Retention)
CIS 7.1 (Establish and Maintain a Vulnerability Management Process)
Compensating Control
Create a dated compliance memo (PDF with file hash recorded) documenting: (1) the KEV entry reference and deadline date, (2) the absence of a CISA standalone advisory as of the deadline, (3) citation of SANS ISC Diary update numbers (through Update 007, April 8, 2026) and Google GTIG UNC6780 reporting as the authoritative threat intelligence basis for remediation actions taken, (4) all remediation steps completed with timestamps and responsible parties. Store this in an immutable location (write-once S3 bucket, SharePoint with version history locked, or printed and signed). For regulated environments (FedRAMP, CMMC, PCI), include explicit mapping of which NIST 800-53 or CIS controls were addressed by each action to demonstrate control-level compliance independent of the CISA advisory.
Preserve Evidence
Archive the full text of each referenced SANS ISC Diary entry (SANS ISC Update 001 through Update 007) and Google GTIG UNC6780 reporting as PDFs with capture timestamps and SHA-256 hashes — these are your evidentiary basis for compliance decisions and may be unavailable or modified in the future. Preserve screenshots or exports of the CISA KEV catalog showing the entry and deadline alongside the absence of a linked CISA advisory at the deadline date, creating a contemporaneous record of the gap. Document the organizational decision log showing who reviewed the intelligence, what actions were authorized, and when — this establishes the chain of custody for compliance decisions made without a CISA advisory anchor.
Recovery Guidance
Before restoring any Trivy instances to production CI/CD pipelines, verify the container image digest or binary hash of every Trivy deployment against the official Aqua Security release hashes published at the official Trivy GitHub releases page — do not trust cached or locally stored images as UNC6780 weaponized the scanner binary itself. Rotate all credentials, tokens, and secrets that were accessible to Trivy execution contexts during the compromise window, including CI/CD platform tokens, container registry credentials, source code repository access tokens, and any cloud IAM roles bound to pipeline service accounts. Monitor CI/CD pipeline execution telemetry and outbound network connections from runner hosts for a minimum of 30 days post-recovery, given the campaign's confirmed active status through April 8, 2026, and the likelihood of persistence mechanisms planted during the access window.
Key Forensic Artifacts
Trivy binary or container image hash: compare SHA-256 of deployed Trivy binary or image digest against official Aqua Security release hashes — a mismatch is definitive evidence of binary tampering by UNC6780
CI/CD pipeline job execution logs showing Trivy invocation arguments, stdout/stderr output, and process exit codes for all runs in the 90-day window prior to detection — anomalous flags, unexpected scan targets, or output redirections indicate weaponized execution
Network flow logs and DNS query logs from pipeline runner hosts scoped to Trivy process execution windows — UNC6780 C2 exfiltration of source code would appear as anomalous outbound connections to non-standard destinations during or immediately after Trivy scan stages
Container registry access logs and source code repository audit logs (GitHub audit log, GitLab audit events, Bitbucket audit log) for read/clone events initiated by Trivy service accounts or pipeline tokens outside normal scan scope — these capture the Cisco-style source code exfiltration path
Secrets manager and credential store access logs (AWS CloudTrail GetSecretValue events, HashiCorp Vault audit log, Kubernetes secret access audit events) for any reads performed by Trivy service account identities — confirms whether the weaponized scanner harvested credentials beyond its intended scan function
Detection Guidance
Monitor for behavioral indicators:
Trivy process execution with unexpected command-line arguments, unusual parent processes, or execution outside scheduled scan windows; Anomalous outbound network connections from Trivy execution contexts; Access to secret management systems, container registries, or source code repositories outside normal scanner scope; Pipeline logs showing credential exfiltration or artifact staging to external repositories. Review CI/CD pipeline logs for failed authentication attempts followed by successful access using different credentials (lateral movement). Cross-reference SANS ISC Diary for updated IOCs as the campaign evolves.
Compliance Framework Mappings
T1552.001
T1610
T1554
T1212
T1059
T1078
+4
CM-7
SI-3
SI-4
SI-7
AC-2
AC-6
+7
A08:2021
A07:2021
A01:2021
2.5
2.6
16.10
6.1
6.2
6.3
+2
MITRE ATT&CK Mapping
T1552.001
Credentials In Files
credential-access
T1610
Deploy Container
defense-evasion
T1554
Compromise Host Software Binary
persistence
T1212
Exploitation for Credential Access
credential-access
T1059
Command and Scripting Interpreter
execution
T1078
Valid Accounts
defense-evasion
T1609
Container Administration Command
execution
T1195.002
Compromise Software Supply Chain
initial-access
T1195.001
Compromise Software Dependencies and Development Tools
initial-access
T1213
Data from Information Repositories
collection
Guidance Disclaimer
