Hand-written parsers, crypto routines and authentication code are where many serious application flaws come from, and replacing them with a vetted library only helps if the library itself is genuine, maintained and kept up to date. MITRE D3FEND names this countermeasure Trusted Library (D3-TL) and defines a trusted library as "a collection of pre-verified and secure code modules or components that are used within software applications to perform specific functions," vetted so that they "do not introduce risks into the application." It sits under the Harden tactic as a child of Source Code Hardening (D3-SCH), and its artefact relation is that it hardens Subroutine. This card explains what D3FEND does and does not say about it, how to decide which libraries count as trusted, how to keep them that way, how to verify the control and where it fails. It is written for application security leads, developers and platform teams; programme-level detail is in the Open Source Security Guide and the Software Composition Analysis (SCA) Guide, which this page links rather than repeats.
Key takeaways
- Reuse beats reinvention for security functions. D3FEND's only claim is that using a trusted library can reduce errors compared with writing code from scratch; NIST's SSDF practice PW.4 says the same: reuse existing, well-secured software when feasible.
- "Trusted" is a decision you document. Nothing marks a library as trusted by default. It becomes trusted when it passes defined checks for authenticity, maintenance, security practice and licensing, and stays trusted only while it keeps passing them.
- Trust decays. New vulnerabilities, abandoned maintenance, a compromised maintainer account or a malicious release turn a trusted library into a liability, so inventory and monitoring are part of the control.
- Thin D3FEND entry. D3FEND gives a definition, a short "how it works" line and one OWASP reference, with a single inferred ATT&CK relation. Practical depth comes from OWASP, NIST and OpenSSF guidance.
- Use the library's secure interfaces. A trusted SQL or templating library still allows unsafe calls; the benefit depends on developers using its safe APIs and secure defaults.
D3-TL at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-TL (d3f:TrustedLibrary) |
| Tactic | Harden |
| Parent technique | Source Code Hardening (D3-SCH): "Hardening source code with the intention of making it more difficult to exploit and less error prone" |
| Siblings | Credential Scrubbing, Domain Logic Validation, Integer Range Validation, Pointer Validation, Reference Nullification, Variable Initialization, Variable Type Validation |
| Digital artefact | Subroutine (D3FEND relation: hardens) |
| D3FEND reference | OWASP: Leverage Security Frameworks and Libraries (Top 10 Proactive Controls 2018, C2) |
| D3FEND consideration | "This resource should not be considered a definitive or exhaustive coding guideline." |
| Main limitation | Moves risk from your code to your supply chain; does not help if the library is compromised, outdated or misused |
How it works
A subroutine that implements a security-sensitive function, such as parsing input, building a database query, encoding output, hashing passwords or verifying a token, is replaced with a call to a library that has been reviewed, tested and used at scale. The library carries the hard-won fixes that a fresh implementation would have to rediscover. OWASP's 2018 control, which D3FEND cites, sets out four practices for third-party libraries:
- Use trusted sources: libraries that are actively maintained and widely used.
- Maintain an inventory: a catalogue of all third-party libraries.
- Keep components up to date: check for publicly disclosed vulnerabilities with tools such as OWASP Dependency-Check and Retire.js.
- Reduce the attack surface: encapsulate the library and expose only the behaviour your software needs.
OWASP's current Proactive Controls carry the topic forward as C6 Keep your Components Secure. It adds two points that matter for D3-TL: prefer the security features of tools you already use over adding a new dependency, and prefer signed packages from official sources. NIST SP 800-218 (SSDF version 1.1, final, February 2022) frames the same idea as practice PW.4: acquire and maintain well-secured components from third parties (PW.4.1), build well-secured in-house components for common needs third parties cannot meet (PW.4.2), and verify that acquired components meet organisation-defined requirements throughout their life cycles (PW.4.4). See the NIST Secure Software Development Framework (SSDF, SP 800-218) Guide and OWASP Top 10 Proactive Controls.
ATT&CK techniques and D3-TL
Relationship type: inferred only, one technique. D3FEND has no hand-made ATT&CK mapping for D3-TL. Its site lists one inferred and experimental relation (D3FEND 1.6.0, checked November 2026): T1505.001 SQL Stored Procedures, because that technique creates a Stored Procedure, which D3FEND models as a kind of Subroutine. The link is structural rather than practical; a trusted library in application code does not stop an attacker with database rights from creating a stored procedure. Detail is in the T1505 Server Software Component Defensive Guide.
The risks D3-TL addresses in practice are flaw classes rather than ATT&CK techniques: injection, broken cryptography, unsafe deserialisation and memory safety errors in hand-written code. The risks it creates sit in supply chain techniques such as T1195.001 Compromise Software Dependencies and Development Tools, covered in MITRE ATT&CK T1195 Supply Chain Compromise. That pairing is NHI Mgmt Group's reading, not a D3FEND mapping.
Deciding what counts as trusted
The OpenSSF Concise Guide for Evaluating Open Source Software gives a practical checklist. The table groups its main questions with the evidence a reviewer can collect.
| Criterion | Question (from the OpenSSF guide) | Evidence to record |
|---|---|---|
| Necessity | Can the dependency be avoided by using existing components? | Why existing platform or framework features are not enough |
| Authenticity | Is it the genuine project from its authorised source, not a malicious fork? Is a similarly named package more popular (possible typosquatting)? | Official repository URL, package name, publisher |
| Maintenance | Significant activity and a release within the past 12 months? Multiple maintainers, ideally from different organisations? | Last release date, maintainer count |
| Security practice | OpenSSF Best Practices badge, Scorecard and deps.dev results, security audits, prompt security fixes, a vulnerability reporting route | Scorecard result, security policy link |
| Vulnerability status | Is the current version free of known significant vulnerabilities? | SCA result at adoption |
| Secure use | Is the API easy to use securely, with secure defaults and security guidance? | Approved usage notes for developers |
| Licensing | A clear, OSI-approved licence that fits the use | Licence identifier |
| Behaviour | Does it show malicious behaviour in an isolated test? Signs of malicious code in install scripts or obfuscated code? | Sandbox test result for high-risk packages |
OpenSSF Scorecard automates part of this. Its checks include Maintained, Code-Review, Branch-Protection, Signed-Releases, Token-Permissions, Vulnerabilities and Dependency-Update-Tool (rated High risk in the Scorecard documentation), Dangerous-Workflow and Webhooks (Critical), and Pinned-Dependencies, SAST, Fuzzing, Security-Policy and SBOM (Medium). A score is an input to the decision, not the decision. See the OpenSSF Scorecard Guide.
Small team or large organisation
- Small teams: a short approved list for security-critical functions (crypto, authentication, parsing, templating, database access), lockfiles, automated dependency updates and one SCA tool cover most of the value.
- Large organisations: an internal package proxy or artefact registry that only serves approved packages, policy-as-code gates in CI, SBOMs per build, and a named owner per critical dependency.
Where it is implemented
| Implementation class | Role in D3-TL |
|---|---|
| Approved component list or policy | Records which libraries are trusted for which function and version range |
| Internal package proxy or artefact registry | Serves only approved packages from official sources; blocks direct pulls from public registries |
| Software composition analysis | Finds known vulnerabilities and licence issues at adoption and continuously after |
| SBOM generation and monitoring | Inventory per build; OWASP's C6 suggests generating SBOMs in the pipeline and checking them against vulnerability data (for example with OWASP Dependency-Track) |
| Dependency update automation | Keeps trusted libraries current; see the Dependency Update Automation Guide |
| Signature and provenance verification | Confirms packages come from the expected publisher; see the Sigstore Guide |
| Static analysis rules | Flags hand-rolled implementations (custom crypto, string-built SQL) where an approved library exists |
Where identity fits
Package registries, build systems and dependency bots run on non-human credentials: publish tokens, CI tokens and bot accounts. A trusted library is only as trustworthy as the tokens that can publish it, and the dependency update bot that opens pull requests is itself a privileged identity in your repositories. Scope those tokens narrowly and review the Scorecard Token-Permissions result for your own projects.
Implementation steps
- List security-critical functions. Identify where code implements cryptography, authentication, session handling, input parsing, serialisation, output encoding and database access.
- Choose one trusted library per function. Prefer platform or framework features first, then evaluate candidates against the criteria above and record the decision.
- Publish usage guidance. For each approved library, document the safe APIs and settings (for example parameterised queries, context-aware encoding) and the unsafe ones to avoid.
- Gate new dependencies. Route package installs through an approved registry or proxy and add a CI check that fails on unapproved packages or known critical vulnerabilities. Start in warn-only mode on a pilot repository.
- Replace hand-rolled code. Migrate custom implementations behind tests; keep the old path until the new one passes the same test suite, which is the rollback route.
- Monitor continuously. Generate an SBOM per build and alert on newly disclosed vulnerabilities, abandoned projects and licence changes for approved libraries.
- Review on a schedule. Re-evaluate each approved library periodically (for example yearly, an NHI Mgmt Group suggestion) and remove it from the list if it no longer meets the criteria.
How to verify it works
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| Applications with a current SBOM | 100% of production applications | No inventory, no trust decision |
| Dependencies from approved sources | Close to 100% | Shows the registry gate is in place |
| Hand-rolled implementations of security functions found by static analysis | Falling to zero | Measures adoption of trusted libraries |
| Median time to update a library after a critical advisory | Within the organisation's patch policy | Trust depends on staying current |
| Approved libraries failing re-evaluation | Each with a replacement plan | Catches abandoned or degraded projects |
A simple negative test: try to add an unapproved package, and a known vulnerable version of an approved one, to a pilot repository, and confirm the CI gate blocks both.
Limits, bypasses and failure patterns
- Trusted once, never again checked: the library was vetted at adoption and then pinned for years. Known vulnerabilities in old versions are the main risk OWASP's C6 lists.
- Typosquats and malicious releases: a package with a near-identical name, or a malicious version pushed from a compromised maintainer account, passes a check based on the name alone. See the Malicious Package and Dependency Confusion Guide.
- Unsafe use of a safe library: string concatenation passed to a query builder's raw method, or a crypto library used in an insecure mode, keeps the original flaw.
- Dependency sprawl: a large library with many transitive dependencies adds more update work and more places to be compromised; OWASP's C6 warns about this.
- Vendored copies: code copied into the repository is invisible to SCA and stops receiving fixes.
- Credentials left in reusable code: shared libraries sometimes ship with test keys or tokens; that is Credential Scrubbing territory, see D3-CS Credential Scrubbing.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-218 (SSDF 1.1) | PW.4 (PW.4.1, PW.4.2, PW.4.4) | Reuse existing, well-secured software; verify acquired components through their life cycle |
| NIST SP 800-53 Rev 5 | SA-15 Development Process, Standards, and Tools; SR-3 Supply Chain Controls and Processes; SR-4 Provenance | Development standards and supply chain controls for components |
| NIST SP 800-53 Rev 5 | SA-22 Unsupported System Components | Replacing libraries that are no longer maintained |
| NIST CSF 2.0 | PR.PS-02, PR.PS-06 | Software maintained and replaced commensurate with risk; secure development practices |
| OWASP Top 10 Proactive Controls | C2 (2018), C6 Keep your Components Secure | D3FEND's reference and its current successor |
| MITRE D3FEND | D3-SCH, D3-TL | Parent and technique |
Related countermeasures
- Pointer Validation (D3-PV), Variable Type Validation (D3-VTV) and Integer Range Validation (D3-IRV): sibling Source Code Hardening techniques for code you still write yourself. See D3-PV Pointer Validation.
- Software Update (D3-SU): keeping deployed components current, the operational side of keeping a library trusted. See D3-SU Software Update.
- The parent, Source Code Hardening (D3-SCH), is summarised in the MITRE D3FEND Guide.
Practitioner checklist
- Name one approved library per security-critical function and record why.
- Check authenticity, maintenance, security practice and licence before adoption.
- Serve dependencies through an approved registry or proxy.
- Generate an SBOM per build and monitor it for new vulnerabilities.
- Automate dependency updates and set a deadline for critical advisories.
- Document safe and unsafe APIs for each approved library.
- Flag hand-rolled security code with static analysis rules.
- Scope publish, CI and bot tokens narrowly.
- Re-evaluate approved libraries on a schedule and retire abandoned ones.
Standards and references
- MITRE D3FEND: Trusted Library (D3-TL)
- OWASP: Leverage Security Frameworks and Libraries (Proactive Controls 2018 C2)
- OWASP: Keep your Components Secure (Proactive Controls C6)
- NIST: SP 800-218 Secure Software Development Framework Version 1.1
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- OpenSSF: Concise Guide for Evaluating Open Source Software
- OpenSSF: Scorecard checks documentation
Related NHI Mgmt Group resources: Open Source Security Guide · Software Composition Analysis (SCA) Guide · SBOM Guide · OWASP Dependency-Track Guide · MITRE D3FEND Guide