PlanDev Security Advisory: Trivy CI Workflow Incident (March 2026)

[dandelany]

Summary

On March 19, 2026, an upstream supply chain compromise affected the Trivy GitHub Action (aquasecurity/trivy-action) used in our PlanDev CI workflows. This only affected development Github workflows used for scanning and publishing packages, and does not impact runtime systems or deployed PlanDev environments. However, it may be relevant if you:

• Maintain a fork or internal copy of PlanDev repositories, and
• Use our GitHub workflows (e.g., publish.yml) or similar configurations

During a limited time window, the compromised action could access data available to the workflow runner. This included a short-lived GITHUB_TOKEN with repository write permissions. Importantly:

• No long-lived secrets (e.g., production credentials, deployment keys, or user data) were exposed
• No credentials persisted beyond the duration of the affected workflow runs

As a precaution, we conducted a comprehensive audit of all affected repositories and infrastructure. We found no evidence of unauthorized access, persistent changes, or compromise of repository state or released artifacts.

Customer Impact

There is no impact for the majority of users. Specifically:

• No impact to runtime systems or deployed PlanDev environments
• No compromise of published artifacts (Docker images, packages, or deployments)
• No exposure of user or developer credentials

Potential Impact (Limited Scope)

This may be relevant only if all of the following are true:

• You maintain a fork or internal copy of one of the following repositories:
  • NASA-AMMOS/aerie
  • NASA-AMMOS/aerie-ui
  • NASA-AMMOS/aerie-gateway
• You run our GitHub publish.yml workflow (or a derivative of it)
• The workflow executed during one of the exposure windows described below

If these conditions do not apply, no action is required.

What Happened

Trivy is an open-source security scanner used to detect vulnerabilities in container images and dependencies. In our PlanDev publish.yml workflows, it is used during CI to scan built images before publishing. Starting on March 19, 2026, a supply chain compromise affected multiple components of the Trivy ecosystem (advisory, discussion), including:

• trivy-action (GitHub Action)
• setup-trivy (invoked internally by the action)
• Specific versions of the Trivy binary and container images

Our workflows referenced the action using a mutable version tag:

uses: aquasecurity/trivy-action@0.24.0

Although this tag appeared versioned, it was not immutable. During the incident, the upstream tag was updated to reference malicious code. As a result, any workflow run during the exposure window resolved this tag to compromised code and executed it within the GitHub Actions runner environment.

Exposure Windows (UTC)

(from upstream Trivy advisory)

Component	Start	End
trivy-action	2026-03-19 17:40	2026-03-20 05:50
setup-trivy	2026-03-19 17:40	2026-03-19 21:44
Trivy 0.69.4	2026-03-19 18:22	~2026-03-19 22:00
Trivy images 0.69.5/6	2026-03-22 15:43	2026-03-23 22:01:50

Primary exposure window:
2026-03-19 ~17:40 → 2026-03-20 ~05:50

Affected Repositories

The following reflects the impact to our PlanDev repositories. If you maintain forks or similar workflows, you should evaluate your own repositories for workflow runs during the exposure windows.

• NASA-AMMOS/aerie - Affected: A workflow run occurred during the primary exposure window and executed the compromised trivy-action

• NASA-AMMOS/aerie-ui - Not affected: A workflow run occurred during a later Trivy binary exposure window, but did not execute a compromised binary file

• NASA-AMMOS/aerie-gateway - Not affected: The vulnerable action was present in workflow, but no workflow runs occurred during any exposure window

Exposure and Risk Analysis

The exposure described in this report applies to the single affected workflow run in the NASA-AMMOS/aerie repository, though we ultimately audited all three repositories as a precaution. During this run, the compromised action had access to a GITHUB_TOKEN with write permissions to the repository and packages. This token:

• Is scoped to the repository
• Is short-lived and typically invalidated when the workflow completes
• In some scenarios (e.g., a job crash), may remain valid for up to six hours, per Github documentation

Potential Impact During Execution

In principle, this level of access could allow modification of repository state during the execution window (for example, pushing commits or creating branches). However, based on public reporting and the nature of the incident, the attack appears to have been focused on credential exfiltration rather than repository manipulation.

While this makes active modification unlikely, the presence of write access means it cannot be ruled out. Accordingly, we treated this as a worst-case scenario and performed a full audit of repository state and activity during the exposure window.

Other Accessible Data

GitHub Actions workflows can expose environment variables and repository secrets to running steps. In this case, the affected job did not reference any repository or organization secrets, and only transient test credentials and standard (non-secret) environment variables were available. These credentials are only used for a short-lived testing environment in CI workflows without sensitive data, but we have nonetheless rotated them to be safe.

As a result, exposure of sensitive credentials is not considered a concern for this incident.

Investigation and Findings

We performed a multi-layer audit of the NASA-AMMOS/aerie repository to determine whether any unauthorized activity occurred during the exposure window. This included reviewing audit logs, repository events, commit activity, and all released artifacts.

At the organization level, we exported GitHub audit logs and reviewed them for permission changes, workflow modifications, or repository configuration updates. These logs are useful for detecting administrative changes, even if they do not capture all commit activity. No suspicious activity was observed.

We also retrieved repository events using the GitHub Events API (including push events and related activity) and filtered them to the defined exposure windows. This was done via script to ensure complete coverage. The Events API provides a reliable record of when refs (branches or tags) were updated, independent of commit timestamps. Because the API only returns a limited number of recent events, this data must be collected soon after an incident. No suspicious actors, refs, or activity were identified. Based on this, we have high confidence that no persistent branches or tags were created or modified during the window.

We reviewed commit activity across all branches, with particular focus on protected branches such as develop. These branches were confirmed to contain only expected commits, with no unexpected changes or history rewrites.

Finally, we audited all outputs produced during the exposure window, including GitHub releases, GitHub Packages (GHCR images), and workflow artifacts. No unexpected or malicious outputs were found.

The scripts used to collect and filter audit logs and repository events can be provided upon request for teams wishing to perform similar analysis on their own repositories.

Findings Summary

• No evidence of unauthorized commits or changes to protected branches
• No evidence of persistent branch or tag creation or modification
• No evidence of malicious releases, packages, or artifacts

We cannot completely rule out the possibility of very short-lived activity (for example, a branch or tag created and deleted within the exposure window). However, there is no evidence of persistent impact to any code or artifacts.

Mitigations Taken

We took the following actions in response to this incident:

Pinning GitHub Actions

All Trivy-related GitHub Actions were updated from mutable tags to immutable commit SHA hashes. This ensures that future workflow runs execute only the exact reviewed code, regardless of upstream changes.

This change has been applied across all affected repositories (aerie, aerie-ui and aerie-gateway), PRs are linked in the References section below.

Credential Rotation

Although no sensitive credentials were exposed, transient E2E test credentials were rotated as a precaution. No action was required for the GITHUB_TOKEN, which is automatically short-lived and expires after the workflow run

Repository and Artifact Audit

As discussed above, we performed a comprehensive audit of repository history and branches, GitHub Events (push and ref activity), releases, packages, and workflow artifacts. Only the token from aerie is believed to have been exposed, but the audit was conducted for all three repositories under a worst-case assumption.

Future Hardening

To reduce the risk of similar incidents, we are implementing the following changes:

Restrict Default GitHub Token Permissions

We are updating workflows to default their GitHub access tokens to read-only permissions. Write permissions will be explicitly granted only where required. This reduces the impact of any future compromise.

Pin All Third-Party Actions

All third-party GitHub Actions will be pinned to immutable commit SHAs rather than tags. This prevents upstream tag mutation from affecting our workflows.

Reduce Transitive Risk in Actions

Pinning GitHub Actions improves our security posture, but is not a complete solution. Actions may include transitive dependencies that are not pinned and remain vulnerable to similar attacks. Therefore we will review third-party actions used in our workflows to better understand:

• What code they execute internally
• Whether they invoke additional actions or external dependencies

Actions with insecure transitive dependencies may be replaced or forked to make them more secure.

Additional Measures Under Evaluation

We are also evaluating:

• Signed Github commits for improved post-incident auditability
• Dependency pinning for other dependencies (e.g. Node & Java dependencies)
• Additional CI monitoring and controls

Conclusion

This incident resulted in the execution of compromised third-party code within a CI workflow due to an upstream supply chain issue.

The exposure was limited to a single workflow run in the NASA-AMMOS/aerie repository, during a short time window, using ephemeral credentials. Based on a comprehensive audit, we found no evidence of repository compromise, no persistent changes, no impact to released artifacts, and no exposure of sensitive credentials.

For the majority of PlanDev users, no action is required. This incident does not affect runtime systems, deployed environments, or standard usage of PlanDev.

This may be relevant only for teams that maintain forks or internal copies of PlanDev repositories and run similar GitHub workflows. In that case, we recommend reviewing workflow runs during the exposure windows described above, auditing repository activity (particularly push events and ref changes), and ensuring that all third-party actions are pinned to immutable commit SHAs.

We are continuing to harden our workflows to reduce exposure to similar supply chain risks in the future. This class of attack has become increasingly prevalent in recent years, and incidents like this are a reminder that CI workflows are part of the trusted computing base and should be treated accordingly. Even though this particular event did not result in major impact, it provides an opportunity to proactively reduce risk by tightening permissions, pinning dependencies, and auditing execution paths before a more severe compromise occurs.

Current repository state is trusted.

References

Upstream Incident

• Trivy Security Advisory (GHSA-69fq-xp46-6x23)
  GHSA-69fq-xp46-6x23
• Trivy Action Compromise Discussion
  Trivy Security incident 2026-03-19 aquasecurity/trivy#10425
• Trivy Action Issue Spice Fails to Load on M1 Macs during Simulation #541
  aquasecurity/trivy-action is compromised aquasecurity/trivy-action#541

GitHub Security Model

• Github Token documentation
  https://docs.github.com/en/actions/concepts/security/github_token
• Compromised runners guidance
  https://docs.github.com/en/actions/concepts/security/compromised-runners

Internal Tracking and Mitigation

• Affected action run
  https://github.com/NASA-AMMOS/aerie/actions/runs/23323078405
• Internal issue
  Compromised aquasecurity/trivy-action detected in GitHub Actions workflows #1805
• Mitigation PRs:
  • Pin trivy-action to save 0.24.0 in response to security compromise #1806
  • pin trivy-action to commit hash for release 0.35.0 to avoid compromised versions plandev-ui#1897
  • pin trivy-action to commit hash for release 0.35.0 to avoid compromised versions plandev-gateway#143

Related Incidents / Context

• LiteLLM security update (March 2026)
  https://docs.litellm.ai/blog/security-update-march-2026