MITRE ATT&CK® Mitigation

M1045: Code Signing

Code Signing is a security process that ensures the authenticity and integrity of software by digitally signing executables, scripts, and other code artifacts. It prevents untrusted or malicious code from executing by verifying the digital signatures against trusted sources. Code signing protects against tampering, impersonation, and distribution of unauthorized or malicious software, forming a critical defense against supply chain and software exploitation attacks. This mitigation can be implemented through the following measures:

Enforce Signed Code Execution:

- Implementation: Configure operating systems (e.g., Windows with AppLocker or Linux with Secure Boot) to allow only signed code to execute. - Use Case: Prevent the execution of malicious PowerShell scripts by requiring all scripts to be signed with a trusted certificate.

Vendor-Signed Driver Enforcement:

- Implementation: Enable kernel-mode code signing to ensure that only drivers signed by trusted vendors can be loaded. - Use Case: A malicious driver attempting to modify system memory fails to load because it lacks a valid signature.

Certificate Revocation Management:

- Implementation: Use Online Certificate Status Protocol (OCSP) or Certificate Revocation Lists (CRLs) to block certificates associated with compromised or deprecated code. - Use Case: A compromised certificate used to sign a malicious update is revoked, preventing further execution of the software.

Third-Party Software Verification:

- Implementation: Require software from external vendors to be signed with valid certificates before deployment. - Use Case: An organization only deploys signed and verified third-party software to prevent supply chain attacks.

Script Integrity in CI/CD Pipelines:

- Implementation: Integrate code signing into CI/CD pipelines to sign and verify code artifacts before production release. - Use Case: A software company ensures that all production builds are signed, preventing tampered builds from reaching customers.

**Key Components of Code Signing**

- Digital Signature Verification: Verifies the authenticity of code by ensuring it was signed by a trusted entity. - Certificate Management: Uses Public Key Infrastructure (PKI) to manage signing certificates and revocation lists. - Enforced Policy for Unsigned Code: Prevents the execution of unsigned or untrusted binaries and scripts. - Hash Integrity Check: Confirms that code has not been altered since signing by comparing cryptographic hashes.

EnterpriseM1045MitigationObject v1.2ModifiedDec 10, 2024, 18:52 UTC (UTC+00:00)

Discuss defensive coverage Back to ATT&CK

M1045: Code Signing describes Code Signing is a security process that ensures the authenticity and integrity of software by digitally signing executables, scripts, and other code artifacts. It prevents untrusted or malicious code from executing by verifying the digital signatures against trusted sources. Code signing protects against tampering, impersonation, and distribution of unauthorized or malicious software, forming a critical defense against supply chain and software exploitation attacks. This mitigation can be implemented through the fo...

Executive priority

M1045: Code Signing is an official MITRE ATT&CK mitigation. Glexia treats it as defensive behavior context for prioritizing monitoring, control validation, and response planning without using the object by itself as an attribution claim.

Technical view

Security teams should validate M1045: Code Signing by reviewing the official ATT&CK relationships, mapped tactics (the mapped ATT&CK tactic context), supported platforms (the platforms named in the official object), and available local telemetry before making detection or mitigation decisions.

Likely telemetry

Official ATT&CK relationships and object metadata

Detection direction

Validate whether M1045: Code Signing appears in your detection coverage and tabletop scenarios.
Use the object to align executive risk language with SOC, incident response, and detection engineering work.
Do not treat ATT&CK relationship context as attribution without corroborating evidence.

Mitigation priorities

Map the object to existing controls and identify missing telemetry or response ownership.
Prioritize mitigations that reduce exposure on the listed platforms and tactics.
Review adjacent ATT&CK relationships before changing policy, detections, or reporting language.

Additional notes and limits

Baseline Glexia take generated from the official MITRE ATT&CK STIX object, source hash, tactics, platforms, and detection fields. It is safe to replace with a richer model-generated take for the same source hash later.

This baseline take is source-grounded and schema-validated, but it does not include environment-specific telemetry, incident evidence, or threat-intelligence corroboration.

Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.

Official MITRE ATT&CK definition

Code Signing

Enforce Signed Code Execution:

Vendor-Signed Driver Enforcement:

Certificate Revocation Management:

Third-Party Software Verification:

Script Integrity in CI/CD Pipelines:

**Key Components of Code Signing**

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

ATT&CK relationship table

Techniques used

This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.

Filter related techniques22 rows

Domain	ID	Name	Relationship / procedure
Enterprise	T1505	Server Software Component	Ensure all application component binaries are signed by the correct application developers.
Enterprise	T1204.003	Malicious ImageSub-technique	Utilize a trust model such as Docker Content Trust with digital signatures to ensure runtime verification of the integrity and publisher of specific image tags.CitationContent trust in DockerCitationContent trust in Azure Container Registry
Enterprise	T1525	Implant Internal Image	Several cloud service providers support content trust models that require container images be signed by trusted sources.CitationContent trust in Azure Container RegistryCitationContent trust in Docker
Enterprise	T1059.002	AppleScriptSub-technique	Require that all AppleScript be signed by a trusted developer ID before being executed - this will prevent random AppleScript code from executing.Citationapplescript signing This subjects AppleScript code to the same scrutiny as other .app files passing through Gatekeeper.
Enterprise	T1059	Command and Scripting Interpreter	Where possible, only permit execution of signed scripts.
Enterprise	T1036.005	Match Legitimate Resource Name or LocationSub-technique	Require signed binaries and images.
Enterprise	T1036.001	Invalid Code SignatureSub-technique	Require signed binaries.
Enterprise	T1546.013	PowerShell ProfileSub-technique	Enforce execution of only signed PowerShell scripts. Sign profiles to avoid them from being modified.
Enterprise	T1036	Masquerading	Require signed binaries.
Enterprise	T1554	Compromise Host Software Binary	Ensure all application component binaries are signed by the correct application developers.
Enterprise	T1601.001	Patch System ImageSub-technique	Many vendors provide digitally signed operating system images to validate the integrity of the software used on their platform. Make use of this feature where possible in order to prevent and/or detect attempts by adversaries to compromise the system image. CitationCisco IOS Software Integrity Assurance - Deploy Signed IOS
Enterprise	T1601.002	Downgrade System ImageSub-technique	Many vendors provide digitally signed operating system images to validate the integrity of the software used on their platform. Make use of this feature where possible in order to prevent and/or detect attempts by adversaries to compromise the system image. CitationCisco IOS Software Integrity Assurance - Deploy Signed IOS
Enterprise	T1543.003	Windows ServiceSub-technique	Enforce registration and execution of only legitimately signed service drivers where possible.
Enterprise	T1059.001	PowerShellSub-technique	Set PowerShell execution policy to execute only signed scripts.
Enterprise	T1505.001	SQL Stored ProceduresSub-technique	Ensure all application component binaries are signed by the correct application developers.
Enterprise	T1543	Create or Modify System Process	Enforce registration and execution of only legitimately signed service drivers where possible.
Enterprise	T1601	Modify System Image	Many vendors provide digitally signed operating system images to validate the integrity of the software used on their platform. Make use of this feature where possible in order to prevent and/or detect attempts by adversaries to compromise the system image. CitationCisco IOS Software Integrity Assurance - Deploy Signed IOS
Enterprise	T1505.004	IIS ComponentsSub-technique	Ensure IIS DLLs and binaries are signed by the correct application developers.
Enterprise	T1546.006	LC_LOAD_DYLIB AdditionSub-technique	Enforce that all binaries be signed by the correct Apple Developer IDs.
Enterprise	T1505.006	vSphere Installation BundlesSub-technique	Enabling the `execInstalledOnly` feature prevents unsigned binaries from being run on ESXi hosts.CitationGoogle Cloud Threat Intelligence ESXi Hardening 2023
Enterprise	T1505.002	Transport AgentSub-technique	Ensure all application component binaries are signed by the correct application developers.
Enterprise	T1127.002	ClickOnceSub-technique	Enforce binary and application integrity with digital signature verification to prevent untrusted code from executing.CitationMicrosoft Learn ClickOnce and Authenticode

Relationship explorer

All related ATT&CK context

Change history

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.

ATT&CK release: 19.2
Object version: 1.2
Created: Jun 11, 2019, 17:01 UTC (UTC+00:00)
Modified: Dec 10, 2024, 18:52 UTC (UTC+00:00)
Raw hash: c3d1de7054b90194...

Imported snapshots across ATT&CK releases(2)

Release	Bundle imported	Object version	Modified	Status	Raw hash
19.2	Aug 6, 2026, 02:58 UTC (UTC+00:00)	1.2	Dec 10, 2024, 18:52 UTC (UTC+00:00)	Current bundle	`c3d1de7054b9…`
19.1	Jul 14, 2026, 09:14 UTC (UTC+00:00)	1.2	Dec 10, 2024, 18:52 UTC (UTC+00:00)	Older bundle	`c3d1de7054b9…`

Raw source

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.

Open mirrored raw JSON Open MITRE-hosted copy

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

[1]
mitre-attackM1045
Open source URL

Source and licensing

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.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use