MITRE ATT&CK® Mitigation

M1016: Vulnerability Scanning

Vulnerability scanning involves the automated or manual assessment of systems, applications, and networks to identify misconfigurations, unpatched software, or other security weaknesses. The process helps prioritize remediation efforts by classifying vulnerabilities based on risk and impact, reducing the likelihood of exploitation by adversaries. This mitigation can be implemented through the following measures:

Proactive Identification of Vulnerabilities

- Implementation: Use tools like Nessus or OpenVAS to scan endpoints, servers, and applications for missing patches and configuration issues. Schedule regular scans to ensure timely identification of vulnerabilities introduced by new deployments or updates. - Use Case: A scan identifies unpatched software, such as outdated Apache servers, which could be exploited via CVE-XXXX-XXXX. The server is promptly patched, mitigating the risk.

Cloud Environment Scanning

- Implementation: Use cloud-specific vulnerability management tools like AWS Inspector, Azure Security Center, or GCP Security Command Center to identify issues like open S3 buckets or overly permissive IAM roles. - Use Case: The scan detects a misconfigured S3 bucket with public read access, which is remediated to prevent potential data leakage.

Network Device Scanning

- Implementation: Use tools to scan network devices for vulnerabilities, such as weak SNMP strings or outdated firmware. Correlate scan results with vendor advisories to prioritize updates. - Use Case: Scanning detects a router running outdated firmware vulnerable to CVE-XXXX-YYYY. The firmware is updated to a secure version.

Web Application Scanning

- Implementation: Use dynamic application security testing (DAST) tools such as OWASP ZAP or Burp Suite to scan for common vulnerabilities like SQL injection or cross-site scripting (XSS). Perform regular scans post-deployment to identify newly introduced vulnerabilities. - Use Case: A scan identifies a cross-site scripting vulnerability in a form input field, which is promptly remediated by developers.

Prioritizing Vulnerabilities

- Implementation: Use vulnerability scoring frameworks like CVSS to assess severity. Integrate vulnerability scanning tools with ticketing systems to assign remediation tasks based on criticality. - Use Case: A critical vulnerability with a CVSS score of 9.8 affecting remote access servers is prioritized and patched first.

*Tools for Implementation*

Open Source Tools:

- OpenVAS: Comprehensive network and system vulnerability scanning. - OWASP ZAP: Dynamic scanning of web applications for vulnerabilities. - Nmap with NSE Scripts: Network scanning with scripts to detect vulnerabilities.

EnterpriseM1016MitigationObject v1.2 Modified Dec 24, 2024, 14:41 UTC (UTC+00:00)

Discuss defensive coverage Back to ATT&CK

Vulnerability scanning matters because it turns unknown exposure into a prioritized remediation queue. For leaders, its value is not the scan itself; it is whether the organization can regularly find misconfigurations, unpatched software, exposed cloud resources, weak network device configurations, and application flaws before those weaknesses support initial access, supply chain compromise, or lateral movement.

Executive priority

Treat M1016 as a resilience and governance control. Executives should ask whether scanning covers public-facing applications, cloud environments, network devices, web applications, endpoints, servers, and software/dependency risk where applicable; whether results are risk-ranked; and whether remediation is tracked to closure through ticketing or equivalent accountability. The relationship context makes this especially relevant to reducing exposure to Exploit Public-Facing Application, Supply Chain Compromise, compromised dependencies/development tools, compromised software supply chains, and Exploitation of Remote Services.

Technical view

SOC, vulnerability management, cloud security, application security, and IR teams should validate that scanning is scheduled, repeatable, and tied to asset ownership. Coverage should include missing patches, configuration issues, overly permissive cloud access, publicly exposed storage, weak SNMP strings, outdated firmware, web flaws such as XSS or SQL injection, and high-risk remote access or remote service vulnerabilities. Because ATT&CK provides no official detection text for this mitigation, teams should focus on evidence that scanning results are actionable: severity scoring, asset criticality, exposure context, ticket assignment, remediation status, and retest results.

Likely telemetry

Vulnerability scanner findings for endpoints, servers, applications, and network devices
Cloud security or cloud vulnerability findings for storage exposure, IAM permissiveness, and configuration weaknesses
Web application scanning results from DAST-style assessments
Network discovery and service exposure data, including Internet-facing services where collected
Patch and software inventory data used to confirm missing or outdated components

Detection direction

Validate scan coverage against the asset inventory; unmanaged, newly deployed, cloud, or Internet-facing assets are common blind spots.
Tune prioritization beyond raw severity by considering exposure, business criticality, exploitability indicators where locally available, and relationship to public-facing applications or remote services.
Correlate scan findings with remediation tickets so SOC and IR teams can quickly determine whether a weakness was known, accepted, patched, or still open during an incident.
Reduce false urgency by distinguishing confirmed exploitable findings from informational scanner output, but avoid allowing noisy results to hide critical externally reachable or remote-service issues.
For supply chain-related coverage, confirm whether dependency and development-tool weaknesses are assessed through appropriate vulnerability or software component processes; generic network scans alone may not be sufficient.

Mitigation priorities

Establish recurring scanning for systems, applications, networks, cloud environments, network devices, and web applications within the organization’s applicable scope.
Prioritize remediation using risk and impact, including severity scoring such as CVSS where appropriate, asset criticality, and exposure to public or remote access paths.
Integrate findings with ticketing or remediation workflows so owners, deadlines, exceptions, and retest evidence are documented.
Address high-risk findings first, especially unpatched public-facing services, remote access infrastructure, cloud misconfigurations, weak network device settings, and application vulnerabilities.
Use rescans or validation checks to confirm closure and maintain audit-ready evidence of the vulnerability management process.

Analyst notes and limits

This is a course-of-action object, not an adversary technique. Its decision value is strongest when evaluated as an operational control: coverage, prioritization, remediation accountability, and validation. The supplied relationships show that vulnerability scanning mitigates initial access through public-facing applications and supply chain compromise, as well as lateral movement through exploitation of remote services.

ATT&CK does not provide official detection guidance or specific platforms for this mitigation object. Tool names in the description are examples, not required products. Local asset inventory, cloud architecture, application portfolio, dependency practices, and remediation evidence are required to judge actual coverage.

Official MITRE ATT&CK definition

Vulnerability Scanning

Proactive Identification of Vulnerabilities

Cloud Environment Scanning

Network Device Scanning

Web Application Scanning

Prioritizing Vulnerabilities

*Tools for Implementation*

Open Source Tools:

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 techniques 5 rows

Domain	ID	Name	Relationship / procedure
Enterprise	T1210	Exploitation of Remote Services	Regularly scan the internal network for available services to identify new and potentially vulnerable services.
Enterprise	T1190	Exploit Public-Facing Application	Regularly scan externally facing systems for vulnerabilities and establish procedures to rapidly patch systems when critical vulnerabilities are discovered through scanning and through public disclosure.CitationOWASP Top 10
Enterprise	T1195.001	Compromise Software Dependencies and Development Tools Sub-technique	Continuous monitoring of vulnerability sources and the use of automatic and manual code review tools should also be implemented as well.CitationOWASP Top 10
Enterprise	T1195	Supply Chain Compromise	Continuous monitoring of vulnerability sources and the use of automatic and manual code review tools should also be implemented as well.CitationOWASP Top 10
Enterprise	T1195.002	Compromise Software Supply Chain Sub-technique	Continuous monitoring of vulnerability sources and the use of automatic and manual code review tools should also be implemented as well.CitationOWASP Top 10

Relationship explorer

All related ATT&CK context

mitigates · Technique T1210: Exploitation of Remote Services Enterprise mitigates · Technique T1190: Exploit Public-Facing Application Enterprise mitigates · Technique T1195.001: Compromise Software Dependencies and Development Tools Enterprise mitigates · Technique T1195: Supply Chain Compromise Enterprise mitigates · Technique T1195.002: Compromise Software Supply Chain Enterprise

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.1
Object version: 1.2
Created: Jun 6, 2019, 16:47 UTC (UTC+00:00)
Modified: Dec 24, 2024, 14:41 UTC (UTC+00:00)
Raw hash: 450b9eaf101af1c1...

Imported snapshots across ATT&CK releases (1)

Release	Bundle imported	Object version	Modified	Status	Raw hash
19.1	May 18, 2026, 07:08 UTC (UTC+00:00)	1.2	Dec 24, 2024, 14:41 UTC (UTC+00:00)	Current bundle	`450b9eaf101a…`

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-attack M1016
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