AN1473: Analytic 1473
Detects anomalous CI/CD workflow execution originating from forked repositories, with pull request (PR) metadata or commit messages containing suspicious patterns (e.g., encoded payloads), coupled with the use of insecure pipeline triggers like `pull_request_target` or excessive API usage of CI/CD secrets. Correlation with unusual artifact generation or secret exfiltration via encoded or external network destination URLs confirms suspicious behavior.
Analyst context for executives and security teams
This analytic is about spotting risky CI/CD activity in SaaS-based development platforms when workflows run from forked repositories and are paired with suspicious pull request or commit content, insecure triggers such as pull_request_target, excessive secrets access, unusual artifact creation, or possible secret exfiltration indicators. For leaders, the practical issue is supply-chain and cloud/SaaS operational risk: a weak pipeline can become a path to expose secrets, generate untrusted artifacts, or disrupt release integrity.
Executive priority
Prioritize this where CI/CD platforms hold production credentials, deployment tokens, signing material, or other sensitive secrets. Security leaders should ask whether forked-repository workflows are allowed, whether insecure trigger patterns are governed, whether secrets access is auditable, and whether SOC/IR teams can quickly reconstruct a suspicious pull request workflow run. This supports business continuity, software supply-chain assurance, compliance evidence around privileged secret handling, and incident decision-making during suspected pipeline compromise.
Technical view
Validate monitoring for SaaS CI/CD workflow executions involving forked repositories, pull request metadata, commit messages, trigger type, API usage against secrets, artifact generation, and outbound destination indicators. Because no ATT&CK tactic or formal detection logic is supplied, teams should treat AN1473 as a detection design objective rather than a ready rule. Detection should correlate multiple signals: fork-origin workflow execution, suspicious encoded content in PR or commit fields, use of pull_request_target or similarly risky triggers, excessive or unusual secrets API activity, unexpected artifacts, and encoded or external URLs that may indicate data movement.
Likely telemetry
- CI/CD workflow run logs from SaaS platforms
- Repository fork and pull request metadata
- Commit message and PR title/body content
- Workflow configuration and trigger type records
- Secrets access or secrets API audit logs
Detection direction
- Correlate forked-repository workflow execution with risky trigger usage rather than alerting on forks alone.
- Inspect PR metadata and commit messages for suspicious encoded payload-like patterns while accounting for legitimate encoded strings used in tests or documentation.
- Baseline normal secrets API usage by workflow, repository, actor, and event type; investigate excessive or unusual access during pull request workflows.
- Flag unusual artifact generation associated with fork-origin workflows, especially when paired with suspicious metadata or secrets activity.
- Where outbound destination telemetry exists, look for encoded or external URLs associated with workflow steps, logs, or artifacts.
Mitigation priorities
- Review CI/CD governance for workflows triggered from forked repositories, especially use of pull_request_target or equivalent high-trust triggers.
- Restrict secrets exposure to untrusted pull request contexts and apply least privilege to automation tokens and service accounts.
- Require review and change control for workflow files that can access secrets or publish artifacts.
- Retain and centralize CI/CD audit, artifact, secrets access, and workflow configuration logs for SOC and incident response use.
- Establish incident response playbooks for suspected pipeline secret exposure, including token rotation, artifact validation, and repository workflow review.
Analyst notes and limits
The supplied object is a detection analytic for SaaS CI/CD environments, not a technique or campaign. It provides a descriptive detection concept but no official detection implementation, no tactic mapping, and no relationship context. The strongest use is as a control-validation prompt for CI/CD telemetry, secrets governance, and suspicious pull request workflow correlation.
Assessment is limited to the official STIX fields, one external MITRE reference, and no supplied relationships. No active exploitation, attribution, specific vendor platform, or guaranteed detection coverage is implied. Local repository models, CI/CD platform features, logging depth, and workflow practices are required to determine applicability and priority.
Analytic 1473
Detects anomalous CI/CD workflow execution originating from forked repositories, with pull request (PR) metadata or commit messages containing suspicious patterns (e.g., encoded payloads), coupled with the use of insecure pipeline triggers like `pull_request_target` or excessive API usage of CI/CD secrets. Correlation with unusual artifact generation or secret exfiltration via encoded or external network destination URLs confirms suspicious behavior.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | 82c89ad0df54… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack AN1473Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.