Most of the techniques that MITRE ATT&CK mitigation M1013 Application Developer Guidance addresses start with a decision a developer made months earlier: a key committed to a repository, a dependency pulled at "latest", a bearer token that works from any device. M1013 is the ATT&CK control for giving developers the knowledge, tools and practices to stop those weaknesses being written in the first place. This page reads M1013 as a control a security team has to implement and prove: which techniques the ATT&CK v20 dataset says it mitigates, which developer rules actually break each one, what the control cannot stop, and how to measure it. It is written for application security leads, platform engineers and detection engineers who own ATT&CK coverage. For general secure coding practice see the Secure Coding Guide; this page does not repeat it.
Key takeaways
- M1013 is mostly a credential and token control. Of the 17 techniques and sub-techniques the v20 dataset maps to it, the highest-impact ones (T1078, T1550.001, T1593.003, T1195.001) are about secrets in code, replayable tokens and unpinned dependencies.
- Guidance only counts when it is enforced. A wiki page on secrets handling changes little; a pre-commit secret scan, a pipeline gate and a pinned-dependency policy change behaviour.
- Token binding is the developer-side answer to token replay. ATT&CK names Microsoft Entra token protection and OAuth DPoP (RFC 9449) as ways to bind a token to a key the attacker does not hold.
- Several mappings are platform-specific. The macOS entries (Hardened Runtime, the
get-task-allowentitlement, bundle structure) only matter if you ship macOS software, so scope coverage claims accordingly. - Coverage is measurable. Secrets found per thousand commits, share of dependencies and CI actions pinned, and share of tokens that are sender-constrained are better evidence than training completion rates.
What M1013 is in ATT&CK v20
ATT&CK describes M1013 as providing developers with "the knowledge, tools, and best practices needed to write secure code, reduce vulnerabilities, and implement secure design principles", integrated throughout the software development lifecycle. Its own description lists five measures: parameterised queries against SQL injection, output encoding against cross-site scripting, authenticating every API endpoint, static analysis in the build pipeline (its example is detecting hardcoded credentials before deployment), and threat modelling with STRIDE at design time. It also names static analysis, dynamic testing and secure-by-default frameworks as implementation tools.
The description is broad, but the technique mappings are narrow. In the ATT&CK v20 Enterprise dataset M1013 has 17 "mitigates" relationships, none of them to revoked or deprecated techniques. That gap matters: a team that delivers secure coding training can claim M1013, yet still leave every technique below unaddressed. The control should be judged against the mappings, not the description.
Techniques M1013 mitigates, prioritised
The table groups the v20 mappings by what a developer has to do differently. "Priority" is an NHI Mgmt Group judgement based on how often the weakness leads to real compromise of non-human identities; the "how it helps" column paraphrases ATT&CK's own per-technique text.
| Priority | Technique (tactic) | How M1013 helps, per ATT&CK | Developer rule that implements it |
|---|---|---|---|
| 1 | T1078 Valid Accounts (initial access, persistence, privilege escalation, stealth) | Applications must not store credentials insecurely: plaintext in code, published in repositories or in public cloud storage | No static secrets in source or images; fetch at runtime from a secrets manager or use workload identity |
| 1 | T1593.003 Code Repositories and parent T1593 Search Open Websites/Domains (reconnaissance) | Developers uploading to public repositories must avoid publishing credentials and API keys | Push protection and pre-commit scanning on every repository, public or private |
| 1 | T1550.001 Application Access Token and parent T1550 (lateral movement) | Token binding, such as Entra token protection or OAuth proof of possession, so a stolen token is useless without the bound secret or device | Sender-constrained tokens (DPoP or mTLS) for high-value APIs; short access token lifetimes |
| 1 | T1195.001 Compromise Software Dependencies and Development Tools and parent T1195 (initial access) | Choose third-party libraries carefully, lock dependencies to specific versions rather than latest, pin GitHub Actions to a commit hash | Lockfiles committed, CI actions pinned to full SHAs, new dependencies reviewed |
| 2 | T1212 Exploitation for Credential Access | Validate authentication requests with one-time passwords, timestamps or sequence numbers, signatures or random session keys (replay resistance) | Nonces and expiry on every signed request; reject replays server-side |
| 2 | T1496.003 SMS Pumping (impact) | CAPTCHA on forms that send SMS | Rate limits and bot challenges on any endpoint that triggers paid messaging |
| 2 | T1574 Hijack Execution Flow and T1574.001 DLL | Include hash values in manifest files to help prevent side-loading of malicious libraries | Load libraries by full path with hash or signature checks; ship signed manifests |
| 3 | T1564 Hide Artifacts and T1564.012 File/Path Exclusions (stealth) | Limit the need for custom antivirus exclusions; install to trusted, permission-protected folders | Installers write to protected program paths; no "exclude our folder" support notes |
| 3 | T1564.009 Resource Forking (stealth) | Use the application bundle structure and its /Resources folder | macOS packaging standard |
| 3 | T1559 Inter-Process Communication and T1559.003 XPC Services (execution) | Enable Hardened Runtime; never ship the com.apple.security.get-task-allow entitlement set to true | Release build signing checks in CI |
| 3 | T1647 Plist File Modification | Follow Apple developer guidance that enables Hardened Runtime | Same signing gate as above |
The table covers all 17 mapped entries (some rows combine a parent with its sub-technique). Everything in priority 1 involves a non-human credential: an API key, a bot token, a cloud access token or a package publishing token.
Implementing the priority rules
Secrets out of code (T1078, T1593.003)
- Source of secrets: applications read credentials at runtime from a secrets manager or obtain them through workload identity. The OWASP Secrets Management Cheat Sheet also warns against baking secrets into container images through
ENVorARGand treats environment variables as a last resort, because they can surface in logs or dumps. See the Secrets Management Guide. - Detection at the developer: OWASP recommends detecting secrets in the IDE, in pre-commit hooks and before the pull request, and using more than one detection tool. Server-side push protection is the backstop. See How to enable GitHub secret scanning push protection and the Developer Secret Scanning Triage.
- Response rule: a secret that reached a remote branch is rotated, not just deleted from history. OWASP notes that restarting an application does not revoke stolen credentials.
- Control mapping: NIST SP 800-53 IA-5(7) No Embedded Unencrypted Static Authenticators is the direct control statement for this rule.
Tokens that cannot be replayed (T1550.001, T1212)
- Proof of possession: RFC 9449 (DPoP, Standards Track, September 2023) binds access and refresh tokens to a client key. The client sends a signed JWT with
typdpop+jwtcarryinghtm,htu,jti,iatand, at the resource server,ath; the authorisation server records the key thumbprint asjktin thecnfclaim. See the DPoP Guide. - Device-bound sessions: Microsoft Entra token protection is a Conditional Access session control that accepts only device-bound sign-in session tokens from supported applications. Microsoft lists native app support on Windows, macOS and iOS/iPadOS as generally available and browser support as preview, and recommends report-only mode and a pilot group before enforcement.
- Replay resistance in custom protocols: for signed webhooks and service-to-service calls, include a timestamp and nonce, reject stale or repeated messages, and sign the method and path, which is what ATT&CK's T1212 text describes.
- Machine-to-machine: where token binding is not available, keep access tokens short-lived and scoped to one audience, so a stolen token has a small blast radius. See the OAuth 2.1, GNAP and FAPI Guide.
Dependencies and build tools (T1195.001)
- Locked versions: commit lockfiles and fail builds that resolve versions outside them.
- Pinned CI actions: GitHub's security hardening guidance says to "Pin references to actions to a commit SHA in your workflow files", to verify the SHA comes from the action's repository rather than a fork, and to grant
GITHUB_TOKENthe minimum required permissions. See How to Pin GitHub Actions to Commit SHAs. - Short-lived pipeline credentials: GitHub recommends OpenID Connect so workflows "stop storing these credentials as long-lived secrets". See the GitHub Actions OIDC Federation Hardening Guide.
- Dependency intake: review new packages for maintainer history and install scripts. See the Malicious Package and Dependency Confusion Guide.
Load paths and platform hardening (T1574, T1559, T1647, T1564)
These are packaging and build-configuration rules rather than coding rules. Put them in the release pipeline as checks: libraries loaded by full path with signature or hash verification, installers that target protected program directories, no product documentation asking customers to exclude your folders from antivirus, and on macOS a signing step that confirms Hardened Runtime is enabled and the get-task-allow entitlement is absent from release builds.
Rolling it out
- Baseline: run a full-history secret scan across all repositories and an inventory of CI workflows, recording unpinned actions and long-lived cloud keys. This gives the starting metrics.
- Stop new leaks first: turn on push protection and pre-commit scanning for every repository in warn mode for two weeks, review false positives, then block.
- Rotate what was found: treat every confirmed historical secret as compromised and rotate it, starting with cloud and package registry credentials.
- Pin and lock: pin actions to SHAs with an automated updater so pins do not go stale, and enforce lockfiles in CI.
- Bind tokens where it is supported: pilot token protection or DPoP on one high-value API in report-only or optional mode, measure client breakage, then enforce.
- Write the guidance last: publish the short developer standard that describes the gates already in place, with the reason for each. Roll back any gate by returning it to warn mode, not by removing it.
What M1013 does not stop
- Stolen developer endpoints: guidance does not help when a developer's laptop or session is compromised and valid tokens are used directly. That needs endpoint controls and M1017 User Training for the phishing step.
- Upstream maintainer compromise: pinning stops silent tag changes but not a malicious commit you later choose to adopt. Code review of updates and least-privilege pipeline secrets cover that gap.
- Unpatched third-party software: developer guidance applies to code you write. Known flaws in products you run fall to M1016 Vulnerability Scanning and M1051 Update Software.
- Legacy clients: token binding only protects clients that support it; mixed estates leave bearer tokens in use for older clients.
Common failure patterns
- Training without gates: annual secure coding modules are counted as M1013 coverage while no pipeline check enforces anything.
- Tag-pinned CI actions: the tj-actions/changed-files compromise (2025) moved version tags to a malicious commit that dumped runner secrets into logs; workflows pinned to full SHAs did not pick it up.
- Deleting instead of rotating: a leaked key is removed from the repository but stays valid.
- Private repositories treated as safe: secrets in private code still leak through forks, clones on laptops and compromised CI tokens.
- Broad pipeline tokens: a default
GITHUB_TOKENwith write access lets any compromised step tamper with the repository. - Coverage claimed for platforms you do not ship: counting macOS-only mappings for a Linux-only product inflates the ATT&CK heatmap.
Measuring coverage
Metrics and target directions are NHI Mgmt Group recommendations.
| Metric | Technique evidence | Source | Target direction |
|---|---|---|---|
| Secrets blocked at push vs found after merge | T1078, T1593.003 | Secret scanning and push protection logs | Blocked share rising, post-merge findings falling |
| Median time to rotate a confirmed leaked secret | T1078 | Ticketing plus secrets manager audit log | Hours, not weeks |
| Share of CI action references pinned to full SHAs | T1195.001 | Workflow inventory scan | Towards 100% |
| Share of repositories with enforced lockfiles | T1195.001 | CI policy results | Towards 100% |
| Share of high-value API calls using sender-constrained tokens | T1550.001 | Authorisation server and API gateway logs | Rising |
| Long-lived cloud keys in pipelines | T1078, T1195.001 | Cloud IAM credential reports | Falling to zero |
Framework mapping
| Framework | Reference | Relevance to M1013 |
|---|---|---|
| NIST SP 800-53 Rev. 5 | SA-8, SA-11, SA-11(1), SA-15, IA-5(7), SR-3 | Engineering principles, developer testing and static analysis, development standards, no embedded static authenticators, supply chain processes |
| NIST CSF 2.0 | PR.PS-06 | Secure software development practices integrated and monitored across the lifecycle |
| NIST SP 800-218 (SSDF 1.1) | Practice groups PO, PS, PW, RV | The practices developer guidance should be built from. See the NIST SSDF Guide |
| ATT&CK related mitigations | M1045 Code Signing, M1047 Audit, M1051 Update Software, M1026 Privileged Account Management | Controls that cover the gaps listed above |
Practitioner checklist
- Map your M1013 claim to the 17 v20 technique relationships, not to training records.
- Enable push protection and pre-commit secret scanning on every repository.
- Rotate every confirmed leaked secret and record time to rotation.
- Pin CI actions to full commit SHAs and set
GITHUB_TOKENto read-only by default. - Replace long-lived pipeline cloud keys with OIDC federation.
- Commit and enforce lockfiles; review new dependencies before first use.
- Pilot DPoP or device-bound token protection on your most sensitive API.
- Add replay protection (timestamp, nonce, signature) to custom signed requests and webhooks.
- Add release-time checks for library load paths and, for macOS builds, Hardened Runtime and entitlements.
Standards and references
- MITRE ATT&CK: Application Developer Guidance (M1013)
- IETF: RFC 9449 OAuth 2.0 Demonstrating Proof of Possession (DPoP)
- OWASP: Secrets Management Cheat Sheet
- NIST: SP 800-218 Secure Software Development Framework Version 1.1
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- Microsoft Learn: Token protection in Microsoft Entra Conditional Access
- GitHub Docs: Security hardening for GitHub Actions
Related NHI Mgmt Group resources: Secure Coding Guide · Secure Software Development Lifecycle (SSDLC) Guide · Secrets Management Guide · MITRE ATT&CK Coverage Mapping Guide