Ransomware activity remained elevated in Q1 2026, continuing the trend established over the past year. According to the State of Ransomware Q1 2026 report from Check Point Research, overall attack volume stayed near historic highs. At the same time, the structure of the ransomware ecosystem changed materially. After two years of increasing fragmentation, activity is consolidating around a smaller number of dominant groups. For organizations, this shift reduces the number of active actors but increases the potential impact of individual incidents. Key Findings: 2,122 organizations were listed on ransomware data leak sites in Q1 2026, making it the second-highest Q1 on record The top […]
As we recognize World Password Day in 2026, the traditional advice to “use a complex password with numbers and symbols” feels hopelessly outdated. Today, a 16-character password is useless if an infostealer malware extracts it directly from a browser cache, or if an employee willingly pastes it into an unmanaged AI chatbot. Welcome to the real World Password Day 2026. Not the one where we remind you to add an exclamation mark to “Password123.” The one where we pull back the curtain on the global industrial marketplace that has quietly been built on the back of our collective password failures — a […]
National Vulnerability Database (NVD) Shifts to Selective Enrichment as CVE Volume Surges
In this post, we examine what NVD’s shift to selective enrichment means for vulnerability workflows and how security teams can maintain visibility and prioritization at scale.
The National Vulnerability Database (NVD) is changing how it processes and enriches vulnerability data in response to sustained growth in CVE submissions.
Under a new model announced by the National Institute of Standards and Technology, NVD will no longer enrich every CVE. Instead, enrichment efforts will focus on a defined subset, including vulnerabilities in the CISA KEV catalog, software used by the federal government, and software designated as critical.
All other CVEs will remain in the database without additional context unless specifically requested.
Rising disclosure volumes are placing pressure on public vulnerability infrastructure, and it has direct implications for how security teams consume and act on vulnerability data.
What Changed in NVD’s Operating Model
For years, NVD aimed to provide consistent enrichment across all CVEs, including severity scoring, affected product data, and supporting context for prioritization.
That approach has not been sustainable since late 2023.
In 2025, Flashpoint tracked 44,509 disclosed vulnerabilities, 14,593 of which had publicly available exploits (and 1,944 more with proof-of-concepts).
CVE submissions increased by 263% between 2020 and 2025, with 2026 already tracking higher year-over-year. Even with increased throughput, NVD has not been able to keep pace.
Under the updated model:
CVEs meeting prioritization criteria will be enriched on an accelerated timeline
CVEs outside those criteria will be labeled and left without enrichment
Re-analysis of modified CVEs will occur selectively
Separate NVD severity scoring will no longer be applied by default
This introduces a significant structural change in how vulnerability data is published and maintained.
The Impact on Vulnerability Workflows
Many security programs rely on NVD enrichment to operationalize CVE data. That enrichment provides the context needed to evaluate risk and determine remediation priorities.
With enrichment applied selectively, teams will encounter a growing number of CVEs that include:
Limited or no severity scoring
Incomplete product and version data
Minimal context on exploitability or impact
No CPE strings that allow for programmatic consumption of data
At the same time, disclosure volume continues to rise, and exploitation timelines remain compressed. This creates a gap between what is disclosed and what can be acted on efficiently.
Security teams will need to account for:
Larger backlogs of CVEs without actionable context
Increased manual effort to evaluate relevance and risk
Greater variability in data quality across sources
These changes affect vulnerability management, threat intelligence, and security operations workflows simultaneously.
Prioritization Criteria Will Not Capture the Full Risk Landscape
NVD’s updated model focuses enrichment on a defined set of criteria, including known exploited vulnerabilities and software relevant to federal systems.
These categories represent important segments of risk, but they do not encompass the full set of vulnerabilities that organizations encounter in practice.
Modern environments include:
Open-source dependencies
SaaS platforms and APIs
Cloud infrastructure and services
Third-party and partner integrations
Many vulnerabilities affecting these environments fall outside formal prioritization frameworks or lack immediate classification within public datasets. As a result, security teams will continue to face exposure from vulnerabilities that are:
Actively exploited but not yet included in prioritized lists
Missing complete metadata or enrichment
Relevant to their environment but not captured by federal-centric criteria
Vulnerability Intelligence Requires Broader Coverage and Deeper Context
As public enrichment becomes more selective, organizations will rely more heavily on alternative sources to maintain visibility and context.
Continuous tracking of exploitation activity and adversary usage
Context on exploit maturity, and remediation
Consistent enrichment that can be integrated into operational workflows
This level of detail supports faster and more accurate decision-making in environments where both volume and speed are increasing.
Flashpoint’s vulnerability intelligence model is built to address these requirements, with a dataset that includes over 7,000 known exploited vulnerabilities and ongoing analyst-driven enrichment across global sources.
What Security Teams Should Do Next
This shift in NVD operations does not change the need to track CVEs. It changes how that data can be used. Security teams should evaluate how their current workflows depend on:
NVD enrichment for prioritization
CVSS scoring as a primary decision input
Completeness of public vulnerability data
From there, teams can take steps to strengthen resilience:
Incorporate sources of vulnerability intelligence that cover CVE and more
Align prioritization to exploitation activity and environmental relevance
Validate coverage across software, cloud, and third-party dependencies
Ensure that enrichment gaps do not delay remediation decisions
A Structural Shift in Vulnerability Data
For many teams, NVD has been a default source of vulnerability context. This change makes clear that its role is narrowing at a time when disclosure volume and prioritization demands are increasing.
At the same time, the role of vulnerability intelligence is expanding.
Security teams need access to data that supports prioritization, not just identification. They need consistent enrichment, faster turnaround, broader coverage, and context tied to real-world activity. As disclosure volumes continue to grow, those requirements become more central to how organizations manage risk.
Flashpoint’s Vulnerability Intelligence provides this level of coverage and context, with analyst-driven enrichment, global visibility across CVE and non-CVE vulnerabilities, and a dataset that includes over 7,000 known exploited vulnerabilities.
Request a demo to see how Flashpoint helps security teams prioritize and act on vulnerability risk with greater precision and confidence.
Flashpoint Surpasses Cataloging 7,000 Known Exploited Vulnerabilities as Disclosure Volume Accelerates
In this post we explore Flashpoint’s latest milestone of surpassing cataloging 7,000 known exploited vulnerabilities and what this means for security teams.
Flashpoint Vulnerability Intelligence has surpassed cataloging 7,000 known exploited vulnerabilities, surpassing another major milestone as vulnerability disclosures accelerate across the global attack surface.
In 2025, Flashpoint tracked 44,509 disclosed vulnerabilities, a pace that continues to accelerate into 2026. Of those, 14,593 had publicly available exploits (1,944 more with proof-of-concepts), giving threat actors immediate pathways to weaponization.
This pace is shaping how exploitation unfolds, with high-impact vulnerabilities being operationalized within hours or days, particularly when they affect widely deployed technologies or core infrastructure.
Security teams are operating within this compressed environment every day. They are reviewing more findings across open-source software, commercial applications, cloud environments, and third-party dependencies, while working within tighter timelines to assess impact and take action.
Flashpoint’s latest milestone of surpassing 7,000 known exploited vulnerabilities (KEVs) cataloged reflects that reality. It highlights how vulnerability management programs are evolving toward prioritization as a core capability, with a focus on vulnerabilities tied to active exploitation and real-world risk.
What The 7,000+ KEV Milestone Means for You
Security teams are operating in a high-volume environment. Vulnerabilities are disclosed continuously across open-source software, commercial applications, cloud environments, and third-party dependencies. At the same time, advancements in automation and code analysis are increasing the rate at which new findings are surfaced.
Each of these findings enters an already crowded workflow. Teams are expected to determine relevance, urgency, and impact quickly, often with limited context. This is where risk-based decision making becomes essential.
Flashpoint tracks hundreds of thousands of vulnerabilities across thousands of sources. Within that dataset, a much smaller percentage shows confirmed exploitation activity. That concentration of risk informs how effective programs allocate time and resources.
Crossing the 7,000+ KEV milestone goes beyond scale to provide greater precision, deeper context, and stronger confidence in how teams prioritize and act on the most critical vulnerabilities.
Validated threats: Each KEV entry reflects observed exploitation in the wild by threat actors, including APT groups, cybercriminal operations, ransomware presence, and automated botnets.
Exploit-aware prioritization: In reality, only a small percentage of tracked vulnerabilities drive real-world incidents. FP KEV provides visibility into that subset so teams can focus remediation efforts where they have immediate impact.
Human-curated intelligence: Every entry is reviewed, validated, and enriched by analysts, with context on exploit maturity, adversary usage, and remediation pathways when available.
This level of clarity allows teams to move faster without sacrificing accuracy. It supports vulnerability management programs that are built around real-world attacker behavior and aligned to current risk.
How Public Vulnerability Data Fits Into the Picture
Public vulnerability catalogs remain useful reference points for tracking disclosures and confirmed exploitation. The CISA Known Exploited Vulnerabilities catalog, for example, gives security teams a curated view into a limited set of vulnerabilities that have been exploited in the wild that impact U.S. government stakeholders.
For many organizations, though, that level of visibility is not enough.
Public catalogs capture only part of the picture. They tend to reflect a narrower slice of exploitation activity, with less detail on how vulnerabilities are being used, which actors are leveraging them, and what defenders should do next. They also rely heavily on CVE-based tracking, leaving gaps around non-CVE exposures and other vulnerabilities that still carry operational risk.
Flashpoint’s FP KEV and Vulnerability Intelligence provide a broader and more actionable view. The advantage is visible in both scale and depth. Of the 7,000 known exploited vulnerabilities in FP KEV, over 800 are missing from CVE. That expanded coverage is paired with the context security teams need to prioritize effectively, including exploit maturity, adversary mapping, affected product detail, and remediation guidance.
Dimension
Public KEV Catalogs
Flashpoint FP KEV
Scope
Varies by provider, with coverage dependent on available sources and methodology
Global, cross-industry coverage
Coverage
CVE-based tracking
CVE and non-CVE vulnerabilities
Context
Limited enrichment
Exploit maturity, adversary mapping, remediation
Update Model
Periodic updates
Continuously updated with analyst input
This is what separates a reference list from an operational dataset. Teams need vulnerability intelligence that supports triage, remediation, reporting, and broader risk reduction efforts. Wider visibility and deeper context make that possible.
The Critical Role of Human-Curated Intelligence
Vulnerability data originates from a wide range of sources with varying levels of completeness and accuracy.
Flashpoint’s intelligence model includes analyst validation to ensure consistency and depth across the dataset.
This process includes:
Reviewing disclosures across public and private sources
Validating exploit availability and usage
Enriching entries with technical and operational context
Analyst input supports:
Accurate classification of vulnerabilities
Clear understanding of exploitation pathways
Timely updates as activity evolves
Supporting Decision-Making Across Teams
Vulnerability intelligence feeds multiple functions across an organization. Teams use this data to align technical actions with current threat activity.
Common use cases include:
Vulnerability management: Align patching priorities with active exploitation trends.
Threat intelligence: Map vulnerabilities to threat actor campaigns and observed behaviors.
Security operations: Tune detection based on known exploit techniques.
Executive reporting: Communicate risk posture using data tied to real-world activity.
Each of these functions relies on consistent, enriched intelligence to maintain alignment.
Proactively Address Vulnerability Risk
Vulnerability discovery continues to expand across software ecosystems, infrastructure, and identity layers.
Security teams require a clear understanding of which issues are relevant to their environment at any given time.
Flashpoint provides primary source intelligence that supports this need through:
Continuous monitoring of vulnerability disclosures and exploitation
Analyst-driven validation and enrichment
Integration-ready data for operational workflows
This approach enables teams to maintain focus, allocate resources effectively, and respond to risk based on current threat activity. Request a demo and learn more today.
Breaking the Patch Sound Barrier: Your Vulnerability Remediation Will Not Keep Up With AI Exploit Speed. So?
Many years ago while at Gartner, I wrote a blog post where I defined the concept of the “Patch Sound Barrier.” (original via Archive if you don’t believe that I was that smart back in 2013 :-)) This was an idea of a maximum speed that a given organization could fix a given vulnerability. If you full throttle beyond that, the engines will whirr louder, but the plane won’t fly faster, essentially.
Gemini illustration for this
The discussion arose from people constantly asking about the “optimal” or “desired” speed of patching. In my time as an analyst, I reviewed plenty of policies as well as “operational practices” (which is what people call it when they don’t actually follow their own policy “because reasons” :-)). BTW, I utterly hated “30 days flat” policies that say that vulnerabilities are fixed within 30 days no matter what, and always steered people to more nuanced risk-based policies.
One concept emerged: Given a particular IT environment, there is often a maximum physical speed at which an organization can patch. That is my Patch Sound Barrier.
Why bring this up now? Because the speed of vulnerability discovery is accelerating and so does exploit dev speed, but for many organizations, the speed of remediation simply cannot be accelerated. It is not accelerating, because it cannot. Full stop.
In the past, my guidance was to focus on better vulnerability prioritization so that you fix “real risks” using CISA KEV, EPSS, CVSS (OK, maybe not in the 2020s) and various tools that analyze the data and give you a ranked list.
But today we will have more vulns and prioritization tools won’t save you. If you have 1,000,000 vulns and 1000 are “risky for you” (however defined, let’s say you have the magical tool that reveals the true and real risk for your organization … ha), you can reduce the risk enough by fixing the 1000, if you have the bandwidth to fix the 1000 (in theory). Now, imagine you have 10m vulns (thanks AI!) and say 5000 are risky. But your bandwidth is there to only fix the 1000. So your risk goes up anyway, while you work as hard as before.
Now, you might say, “Anton, you’re making absolute statements. Surely things are flexible given enough money, enough talented engineers, and these days, enough LLM tokens?”
This is true in theory. But notice I said, “given the IT environment.”
There are definitely methods for accelerating remediation in a modern, beautifully and carefully designed environment (check our podcast episode 109 for those ideas).
But let’s review the scoreboard:
The speed of vulnerability discovery? Increased.
The speed of exploit development? Increased.
The speed of remediation in legacy environments? Unchanged.
OK, some of you might still think “cannot” is too harsh. But people at modern organizations — all DevOps, CI/CD, open source and now AI agents — sometimes cannot comprehend what it takes to deal with a 1990s-era “DBA from Hell” who views his beloved database as a pet, not cattle, and will only allow a patch twice a year on a rigid schedule. Don’t even get me started on OT or the sea of unpatched edge appliances out there (there are “forti” millions of them there, I hear …)
So, yes, I spent years providing recommendations on how to deal with this “vulnerability flood.” This isn’t just about the current fascination with AI; at one point, the “boogeyman” was Metasploit, or something else. Or, as old people told me, SATAN / SANTA in the mid-1990s.
The fact remains: there are more risky vulns than you have time / capability. Today. AI can find the bugs in milliseconds, but it still can’t convince a legacy middleware admin to reboot a production server on a Tuesday. Or in July. Or in 2026. Or this freakin’ century …
Before we go there, we must remember about reducing risk without remediating vulnerabilities. This was often the most insightful bit I shared with clients back in my analyst days: Sometimes your focus must be on reducing your risk, rather than fixing the bug. Kinda “assume the breach”, but for vulns: “assume you can’t patch” then what?
So, how do you get speed to break through the sound barrier (alert: these do NOT apply to everybody):
Brutally destroy legacy systems; if it cannot be patched quickly and safely, don’t use it. Think “SaaS and Chromebooks” (and cloud) world. Don’t think 1980s ERP crap.
Modernize. Kill pets. Grow cattle. Ideally, get replaceable tiny insects as cattle. They are simpler, more replaceable and less cute. Think “pets -> cattle -> insects.” [P.S. I do not recall where I got this idea, if I stole this from you, I am sorry — happy to restore credit if you tell me]
Evolve IT culture to accept automatic patching, everywhere. If Chrome can autopatch 1b systems safely for 10 years, perhaps there is a way to do it, eh?
Eliminate the risk entirely (e.g., via micro-segmentation or data avoidance) when patching is impossible. If you cannot remove the vuln, remove the connection, the system or the entire business process.
Shift focus from patching to overall IT lifecycle velocity by decoupling the application from infrastructure. In faster IT, patching is faster. Fight friction, just like you fight toil.
These are some ideas on how to shift from “floor the gas” to “build a supersonic plane” to break the patch sound barrier! Are you still debating patch cycles, or are you architecting your way out of the need for them? Please share more!
As organizations scale their cloud infrastructure, maintaining proper lifecycle management of Amazon Machine Images (AMIs) is a critical component of their security and risk management goals. AMIs provide the essential information required to launch Amazon Elastic Compute Cloud (Amazon EC2) instances, however; they present security and compliance challenges if not tracked and managed throughout their lifecycle. This blog post explores how organizations can meet their evolving security and compliance requirements by managing potential vulnerabilities across the AMIs deployed throughout their AWS environment.
At the end of 2024, AWS announced lineage supportfor Amazon EC2, providing source details for your AMIs. With this lineage information, you can trace copied or derived AMIs back to their original source. The source AMI information is available for AMIs that were created using specific API commands like CreateImage, CopyImage, and CreateRestoreImageTask. If the AMI was created using a different API command, the ID and AWS Region of the source AMI don’t appear, which can create visibility gaps that potentially impact security and compliance efforts.
To address these gaps and provide comprehensive AMI governance, organizations need to build additional capabilities to analyze the scope of impact of Common Vulnerabilities and Exposures (CVEs), ensure deployed resources originate from an approved golden image, and respond to audit inquiries that require a clear chain of custody for AMIs. A well-designed solution should also help track and enforce approved AMI creation patterns across all accounts and AWS Regions. The AMI lineage solution described in this post is designed to help you manage your organization’s AMI hierarchy and lifecycle, including tracking AMI origins and usage throughout its AWS environment. By implementing this solution, your security teams can quickly understand the scope of impact when security vulnerabilities are discovered, help ensure compliance with organizational policies, and maintain better visibility into their AMI estate.
The solution in this blog post uses Amazon Neptune, a high-performance graph database, along with native AWS security services to maintain a comprehensive view of AMI relationships and enable proactive security monitoring. With the solution in place, you can enforce controls on AMI sourcing, including validation of marketplace AMIs through service control policies (SCPs), and maintain compliance with organizational and regulatory requirements throughout the AMI lifecycle.
Solution overview
AMI Lineage provides a comprehensive governance solution that uses AWS security services and Neptune to create and maintain a hierarchical graph representation of their AMI relationships. This solution helps security and compliance teams understand the complete history of their AMIs including where they originated from, enforce organizational policies such as requiring all AMIs to be encrypted, and rapidly assess security impacts across their organization. The solution integrates core AWS services with security and governance capabilities. The core components of the solution in the security tooling account are:
Neptune: A purpose-built, high-performance graph database securely stores and manages the AMI relationship data.
AWS Lambdafunctions serve as the processing engine for the solution. They process AMI lifecycle events (such as CreateImage, CopyImage, DeregisterImage), evaluate them against compliance rules, and update the Neptune graph database. The functions are configured with least-privilege AWS Identity and Access Management (IAM) permissions to enhance security.
Amazon API Gateway provides secure REST endpoints for lineage queries and security assessments. Authentication is handled using a combination of API keys and IAM roles to help ensure that only authorized users and systems can access the data.
From a governance perspective, this solution provides comprehensive AMI origin validation to help ensure AMIs come from approved sources, including the validation of AWS Marketplace AMIs against a list of trusted vendors. Lifecycle management capabilities enforce AMI retention policies and deprecation processes. Compliance monitoring tracks adherence to organizational and regulatory requirements, while security event scope assessment capabilities quickly identify affected resources when security vulnerabilities are discovered. A detailed audit trail maintains a complete history of AMI creation, modification, and usage patterns.
Architecture
The AMI Lineage solution follows AWS security best practices with a multi-account deployment architecture designed to maximize security while maintaining operational efficiency. The architecture distributes responsibilities across three primary account types: an organization management account, a centralized security tooling account, and multiple member accounts.
This architectural approach helps ensure that sensitive operations and data remain centralized in the security tooling account while enabling distributed monitoring and policy enforcement across the organization. The clear separation of concerns enhances security while maintaining the scalability needed for large-scale AWS deployments.
Figure 1: AMI Lineage solution architecture and workflow
The workflow and architecture shown in figure one includes the following:
Policy enforcement: Theorganization management account is the central point for control. It uses AWS Organizations to enforce SCPs that prevent non-compliant AMI actions across the member accounts.
Event capture: When an AMI lifecycle event (like CreateImage or CopyImage) occurs in a member account, a local Amazon EventBridge rule captures it.
Centralized processing: The event is securely forwarded from the member account’s EventBridge to the central EventBridge in the security tooling account.
Data ingestion and analysis: A Lambda function is triggered in the security tooling account. This function processes the event, analyzes it for compliance, and updates the Neptune graph database with the new AMI relationship data. AWS Security Hub and Amazon GuardDuty in the security tooling account also receive and analyze findings from member accounts.
Query and visualization: Security teams query the lineage data through a secure API Gateway endpoint. By doing this, they can to visualize AMI hierarchies, investigate security findings from Security Hub, and assess the scope of impact for a given AMI.
The organization management account serves as the central control point for policy enforcement and organizational oversight. This account hosts SCPs that prevent non-approved AMI usage across the organization and manages organization-wide EventBridge rules that capture AMI events from member accounts. Cross-account trust policies configured in this account enable secure communication between the management account and the security tooling account.
Additionally, the management account establishes Security Hub in delegated administrator mode, designating the security tooling account as the centralized security administrator for the organization. From the security tooling account, Security Hub can be then configured to aggregate all Regions down to one core Region for easier evaluation by security personnel.
The security tooling account acts as the central hub for AMI lineage processing and storage. This account hosts the Neptune graph database cluster with encrypted storage, helping to ensure that AMI relationship data is securely maintained. Lambda functions running in this account process events, handle API requests, and evaluate compliance with least-privilege permissions. API Gateway provides secure REST endpoints for lineage queries and security assessments. Security Hub custom insights and findings are centralized here in the security tooling account as the Security Hub delegated administrator account, along with Amazon Simple Notification Service (Amazon SNS) topics for notifications and alerts. The Amazon Virtual Private Cloud (Amazon VPC) infrastructure supporting these services is also deployed in the security tooling account, providing network-level isolation and security.
The solution enables distributed monitoring and enforcement by deploying lightweight components into each member account across the organization. Each member account includes AWS Config rules for continuous compliance monitoring, cross-account IAM roles to enable secure access from the security tooling account, and local EventBridge rules that forward AMI-related events to the central processing system.
Security and compliance integration extends throughout the solution. IAM manages least-privilege access control and permissions across components. AWS CloudTrail records API activity for audit trails and compliance reporting, while Security Hub centralizes security findings and compliance status across your AMI estate. GuardDuty provides threat detection for AMI-related activities. SCPs enforce organization-wide controls on AMI creation and usage patterns, and AWS Config tracks AMI configuration changes and evaluates compliance rules.
How it works
The AMI Lineage solution operates through a continuous monitoring and automated response system that maintains comprehensive visibility into your AMI landscape. When AMI lifecycle events occur in your organization, EventBridge rules capture these activities, including creation, copying, modification, and deregistration events. Lambda functions in the security tooling account are then called upon to process these events with appropriate security controls and update the Neptune graph database in real-time, while CloudTrail logs provide a comprehensive audit trail of AMI-related activities.
The system tracks critical security and compliance metadata that forms the foundation of effective AMI governance. This includes:
Source AMI information and validation status to help ensure lineage integrity
Creation method and timestamp data for comprehensive audit trails
Cross-Region and cross-account relationships to understand the full scope of AMI distribution
Instance launch history with security context to track usage patterns
AMI state changes including deprecation and deregistration for lifecycle management
Compliance status along with policy violations to maintain organizational standards.
Security teams use this comprehensive data through secure API calls to visualize complete AMI hierarchies and relationships, providing clear insight into how AMIs are related across your infrastructure. The compliance of your AMI estate is continuously tracked through a combination of services:
Detection: AWS Config rules deployed in member accounts check for policy violations (for example, incorrect tags and public permissions).
Aggregation: These findings, along with vulnerability data from services like Amazon Inspector, are aggregated in AWS Security Hub.
Correlation: Lambda functions in the security tooling account correlate this information with the lineage data in Neptune. Because of this correlation, you can see not just that an AMI is non-compliant, but also its entire downstream impact. When security events like CVE findings are discovered, teams can quickly assess the scope of impact across their entire AMI estate. The solution monitors AMI usage patterns for security anomalies and enforces governance controls through automated policy checks.
The solution provides robust automated policy enforcement capabilities that operate continuously to maintain security and compliance. The system helps ensure that only approved AMIs with verified lineage history can be used to launch new instances, automatically blocking attempts to use non-compliant images. SCP controls on AMI creation and usage are enforced organization-wide, preventing unauthorized AMI operations before they can impact your environment. When policy violations are detected, the system can trigger automated responses to security events and maintain compliance with organizational standards through real-time enforcement.
Implementation
Before deploying the AMI Lineage solution, you need to establish the proper security and governance foundation across your organization. Your AWS Organizations management account requires administrative permissions, and your organization must be enabled with all features to support the policies used in this solution. You will also need a dedicated security tooling account to host the solution’s core components, with cross-account IAM roles configured to allow secure access. Finally, essential security services must be configured at the organization level, including Security Hub, CloudTrail organization trails for audit logging, and encryption keys using AWS Key Management Service (AWS KMS) for data protection.
The complete AMI Lineage solution is available as open source code in the AWS Samples repository. You can clone the repository and follow the deployment instructions. The repository includes the necessary AWS CloudFormation templates, Lambda functions, and deployment scripts referenced in the following phases.
Deployment
The deployment process follows a five-phase approach that builds security and compliance capabilities progressively:
Security foundations
Security controls
EventBridge rules
Core infrastructure
Compliance and monitoring
Phase 1 – Establishing security foundations
The first phase establishes the security foundation by configuring AWS Organizations security services. This involves enablingSecurity Hub in the management account and designating the security tooling account as the delegated administrator, enablingnullGuardDuty with the security tooling account configured as thenulldelegated administrator, and enabling an organizational wide CloudTrail trail for audit logging.
# In Organization Management Account:
# Enable Security Hub and set security tooling account as delegated admin
aws securityhub enable-organization-admin-account \
--admin-account-id <security-tooling-account-id>
# Enable GuardDuty organization with security tooling account as admin
aws guardduty enable-organization-admin-account \
--admin-account-id <security-tooling-account-id>
# Create organization trail with encryption aws cloudtrail create-trail \
--name ami-lineage-trail \
--s3-bucket-name <your-secure-bucket> \
--is-organization-trail \
--kms-key-id <your-kms-key-id> \
--enable-log-file-validation
Phase 2 – Security controls
The second phase deploys base security controls through organization-wide SCPs. These policies enforce AMI governance controls by preventing the use of non-approved AMIs and helping to ensure that proper tagging and approval workflows are followed.
The third phase deploys organization-wide EventBridge rules from the management account to capture AMI events across member accounts and forward them to the security tooling account for processing. These rules listen for specific API calls captured by CloudTrail.
An example of the event pattern used to capture CreateImage and CopyImage events looks like this:
{
"source": ["aws.ec2"],
"detail-type": ["AWS API Call via CloudTrail"],
"detail": {
"eventSource": ["ec2.amazonaws.com"],
"eventName": [
"CreateImage",
"CopyImage",
"RegisterImage",
"DeregisterImage"
]
}
}
# In Organization Management Account:
# Deploy organization EventBridge rules
cd deployment-scripts/organization
./deploy-organization-resources.sh
Phase 4 – Core infrastructure
The fourth phase focuses on core infrastructure deployment in the security tooling account. This is where the primary processing and storage components are deployed, following security best practices by centralizing sensitive operations in a dedicated account.
# Switch to Security Tooling Account context
# Deploy Neptune cluster with encryption in security tooling account
cd deployment-scripts/shared
./deploy-shared-resources.sh
This deployment script handles multiple components in the security tooling account. The Neptune cluster deployment includes encryption and VPC configuration to help ensure secure storage and access to AMI lineage data. Lambda functions are deployed with security controls and configured with VPC attachment, which allows for secure Neptune access in the VPC, appropriate IAM roles with least-privilege permissions, and environment variables for secure configuration. API Gateway provides secure REST endpoints for external access to AMI lineage data and security assessments.
Phase 5 – Compliance and monitoring
The fifth phase establishes comprehensive compliance and monitoring capabilities across member accounts. AWS Config rules are deployed to continuously monitor AMI compliance across your organization, while EventBridge rules forward AMI events to the central processing system.
# In each Member Account:
# Deploy AWS Config Rules and monitoring capabilities
cd deployment-scripts/child-account
./deploy-child-account-resources.sh
After deployment, thorough verification helps ensure that security configurations are properly implemented. This includes validating IAM permissions to help ensure least-privilege access, testing security controls to verify SCP enforcement, validating encryption settings acrosscomponents, and confirming that the security tooling account is properly configured as the Security Hub delegated administrator.
Using AMI Lineage
When deployed, AMI Lineage provides security operations and compliance monitoring capabilities through its API hosted in the security tooling account and automated monitoring systems. Security teams can query and receive complete AMI security relationships to understand the full context of AMIs in their environment.
When investigating AMIs, the system provides detailed security context including source validation information that confirms:
Whether AMIs come from marketplace sources or trusted accounts
Compliance status that shows patch levels and policy adherence
Vulnerability status with CVE findings and scan results
Comprehensive lineage data showing the complete chain of AMI relationships and approval history
# Get complete security context for an AMI (API Gateway in Security Tooling Account)
curl -X GET "https://<api-gateway-id>.execute-api.<region>.amazonaws.com/v1/api/v1/ami/ami-1234567890abcdef0/security-context?include_compliance=true" \
-H "x-api-key: <your-api-key>"
For security impact assessments, such as when a new CVE is discovered, the solution provides a powerful scope of impact analysis. By querying the API with a specific finding, security teams can rapidly determine every affected resource across their entire organization that stems from a compromised or vulnerable AMI. Using that information, they can understand the full scope of their exposure and begin remediation. See Security best practices in Amazon API Gateway for helpful considerations while using API Keys.
This analysis returns impact information including:
Affected AMIs in the lineage chain
Running instances requiring immediate remediation
Affected AWS accounts and regions for coordinated response
Associated auto-scaling groups and launch templates that need updates
Compliance impact assessment for regulatory reporting
Detailed remediation steps prioritized by risk level.
Compliance monitoring operates continuously through automated assessment capabilities that evaluate your AMI estate against organizational policies and regulatory requirements. Teams can generate comprehensive compliance reports that show adherence to security standards across their entire infrastructure.
The solution provides security automation and remediation through configurable automated responses to security events. Security Hub, operating in delegated administrator mode from the security tooling account, can be configured to automatically respond to findings by stopping instances using AMIs with critical vulnerabilities, quarantining instances launched from unapproved sources, and sending immediate notifications for high-severity findings.
Security visualization and reporting capabilities, centralized in the security tooling account, provide real-time dashboards showing:
Compliance status across the organization
Scoping visualization for rapid decision-making
AMI approval workflow status for process monitoring
Patch compliance metrics for maintaining security posture
Automated remediation activity logs for audit purposes
Custom security reports tailored to specific organizational needs.
For security investigations and audit purposes, the solution maintains a queryable audit trail that provides a complete history of AMIs, including creation and modification events, security scanning results and findings, approval workflow history, and compliance status changes over time.
# Query comprehensive audit history (Security Tooling Account API)
curl -X GET "https://<api-gateway-id>.execute-api.<region>.amazonaws.com/v1/api/v1/ami/ami-1234567890abcdef0/lineage?direction=both&depth=10" \
-H "x-api-key: <your-api-key>"
Clean up
To decommission the AMI Lineage solution, use the following steps to prevent dependency errors. The process is the reverse of the deployment.
(Optional) Back up your data. Before you begin, export critical data for your audit and compliance records. This includes generating final compliance reports from the API or creating a final snapshot of the Neptune database (you will be prompted to do this when you delete the cluster).
Run cleanup in member accounts. Sign in to each participating member account and run the cleanup script from the deployment files. This removes the local EventBridge rules, AWS Config rules, and cross-account IAM roles.
# In each Member Account
cd deployment-scripts/child-account
./cleanup-child-account-resources.sh
# Removes Config rules and cross-account roles from each member account
Run cleanup in the security tooling account. Sign in to your security tooling account and run the cleanup script. This decommissions the core solution, including the API gateway, Lambda functions, Neptune cluster, and the associated VPC.
# Clean up security tooling account
cd deployment-scripts/shared
./cleanup-shared-resources.sh
# Removes Neptune, Lambda, API Gateway, SNS, and Security Hub components
Run cleanup in the organization management account. Sign in to your organization management account to remove the organization-level resources.
Run the cleanup script to remove the organization-wide EventBridge rules.
# Clean up organization management account
cd deployment-scripts/organization
./cleanup-organization-resources.sh
# Removes SCPs, EventBridge rules, and cross-account trust policies
In the AWS Organizations console, detach and delete the AMI-Governance-Controls SCP.
In the Security Hub and GuardDuty consoles, remove the security tooling account as the delegated administrator.
Delete final data and encryption keys. After the solution’s infrastructure is removed, you can delete the remaining assets.
In the organization management account,schedule the deletion of the KMS keys you created for encrypting the solution’s data.
Conclusion
In this blog post, we showed you how you can use the AMI Lineage solution to build a comprehensive approach to tracking the complete history of your AMIs from creation to decommissioning. By storing this data in an Amazon Neptune graph database, you can build a hierarchical view of the relationships between your EC2 instances and the AMIs they were launched from. You learned how that data can be used to improve security response and remediation and assist in auditing and compliance activities.
The solution uses AWS Organizations to provide preventative controls to help ensure that only approved AMIs are used and integrates AWS security services like Amazon GuardDuty, AWS Security Hub, and AWS Config to add additional layers of security monitoring and management. Finally, you saw how the solution can be used during a security event or when new CVEs are published, so that you can rapidly discover which systems are affected and automate responses based on those findings.
While this solution provides powerful capabilities, it’s important to consider the operational and cost aspects. The core components, particularly Neptune, have associated costs that will scale with the size of your AMI estate. We recommend implementing cost monitoring and alerts as part of your deployment. Furthermore, because the solution is event-driven, you should plan a one-time backfill process to ingest your organization’s existing AMI history into the graph database. For organizations that require this level of granular control and visibility, these operational considerations are offset by the significant gains in security posture and compliance automation.
AMI Lineage transforms AMI governance from a manual, error-prone process into an automated, comprehensive security capability that scales with your organization’s growth. By implementing this solution, your organization can gain the visibility, control, and automated response capabilities needed to maintain a strong security posture while enabling rapid, secure deployment of infrastructure across its AWS environment.
If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, contact AWS Support.
Navigating 2026’s Converged Threats: Insights from Flashpoint’s Global Threat Intelligence Report
In this post, we preview the critical findings of the 2026 Global Threat Intelligence Report, highlighting how the collapse of traditional security silos and the rise of autonomous, machine-speed attacks are forcing a total reimagining of modern defense.
The cybersecurity landscape has reached a point of total convergence, where the silos that once separated malware, identity, and infrastructure have collapsed into a single, high-velocity threat engine. Simultaneously, the threat landscape is shifting from human-led attacks to machine-speed operations as a result of agentic AI, which acts as a force multiplier for the modern adversary.
Flashpoint’s 2026 Global Threat Intelligence Report
Our report uncovers several staggering metrics that illustrate the industrialization of modern cybercrime:
AI-related illicit activity skyrocketed by 1,500% in a single month at the end of 2025.
3.3 billion compromised credentials and cloud tokens have turned identity into the primary exploit vector.
From January 2025 to December 2025, ransomware incidents rose by 53%, as attackers pivot from technical encryption to “pure-play” identity extortion.
Vulnerability disclosures surged by 12% from January 2025 to December 2025, with the window between discovery and mass exploitation effectively vanishing.
These findings are derived from Flashpoint’s Primary Source Collection (PSC), a specialized operating model that collects intelligence directly from original sources, driven by an organization’s unique Priority Intelligence Requirements (PIR). The 2026 Global Threat Intelligence Report leverages this ground-truth data to provide a strategic framework for the year ahead. Download to gain:
A Clear Understanding of the New Convergence Between Identity and AI Discover how threat actors are preparing to transition from generative tools to sophisticated agentic frameworks. Learn how 3.3 billion compromised credentials are being weaponized via automated orchestration to bypass legacy defenses and exploit the connective tissue of modern corporate APIs.
Intelligence on the “Franchise Model” of Global Extortion Gain deep insight into the professionalized operations of today’s most prolific threat actors. From the industrial efficiency of RaaS groups like RansomHub and Clop to the market dominance of the next generation of infostealer malware, we break down the economics driving today’s cybercrime ecosystem.
A Blueprint for Proactive Defense and Risk Mitigation Leverage the latest trends, in-depth analysis, and data-driven insights driven by Primary Source Collection to bolster your security posture by identifying and proactively defending against rising attack vectors.
“As attackers automate exploitation of identity, vulnerabilities, and ransomware, defenders who rely on fragmented visibility will fall behind. To keep pace, organizations must ground their decisions in primary-source intelligence that is drawn from adversarial environments, so that decision-makers can get ahead of this accelerating threat cycle.”
Josh Lefkowitz, CEO & Co-Founder at Flashpoint
The Top Threats at a Glance
Our latest report identifies four driving themes shaping the 2026 threat landscape:
2026 Is the Era of Agentic-Based Cyberattacks
Flashpoint identified a 1,500% rise in AI-related illicit discussions between November and December 2025, signaling a rapid transition from criminal curiosity to the active development of malicious frameworks. Built on data pulled from criminal environments and shaped by fraud use cases, these systems scrape data, adjust messaging for specific targets, rotate infrastructure, and learn from failed attempts without the need for constant human involvement.
“2026 is the era of agentic-based cyberattacks. We’ve seen a 1,500% increase in AI-related illicit discussions in a single month, signaling increased interest in developing malicious frameworks. The discussions evolve into vibe-coded, AI-supported phishing lures, malware, and cybercrime venues. When iteration becomes cheap through automation, attackers can afford to fail repeatedly until they find a successful foothold.”
Ian Gray, Vice President of Cyber Threat Intelligence Operations at Flashpoint
Identity Is the New Exploit
Flashpoint observed over 11.1 million machines infected with infostealers in 2025, fueling a massive inventory of 3.3 billion stolen credentials and cloud tokens. The fundamental mechanics of cybercrime have shifted from breaking in to logging in, as attackers leverage stolen session cookies to behave like legitimate users.
The Patching Window Is Rapidly Closing
Vulnerability disclosures surged by 12% in 2025, with 1 in 3 (33%) vulnerabilities having publicly available exploit code. The strategic gap between discovery and weaponization is increasingly vanishing, as evidenced by mass exploitation of zero-day vulnerabilities in as little as 24 hours after discovery.
Ransomware Is Hacking the Person, Not the Code
As technical defenses against encryption harden, ransomware groups are pivoting to the path of least resistance: human trust. This approach has led to a 53% increase in ransomware, with RaaS groups being responsible for over 87% of all ransomware attacks.
Build Resilience in a Converged Landscape
The findings in the 2026 Global Threat Intelligence Report make one thing clear: incremental improvements to legacy security models are no longer sufficient. As adversaries transition to machine-speed operations, the strategic advantage shifts to organizations that can maintain visibility into the adversarial environments where these attacks are born.
Protecting organizations and communities requires an intelligence-first approach. Download Flashpoint’s 2026 Global Threat Intelligence Report to gain clarity and the data-driven insights needed to safeguard critical assets.
The cybersecurity community is still grappling with a sobering realization: one of the most ubiquitous tools in the developer’s toolkit, Notepad++, was hiding a critical vulnerability for over six months. Being so deeply embedded in daily workflows, many organizations did not realize they were vulnerable until a recent security update pulled back the curtain on a sophisticated Chinese state-sponsored campaign, dubbed “Lotus Blossom.”
Investigations have confirmed that the issue wasn’t just a coding error, it was a compromise at the hosting provider level. This means that for much of 2025, even organizations that followed best practices were still potentially open to backdoors from Chinese advanced persistent threat (APT) groups. Here is what you need to know to secure your environment.
Understanding the Notepad++ Vulnerability (CVE-2025-15556)
The vulnerability, tracked as CVE-2025-15556 (VulnDB ID: 430205), exploits a critical flaw in the Notepad++ updater component, WinGUP. In versions prior to the February 2026 patch, the updater failed to verify the file integrity signatures of downloaded installers.
By exploiting this lack of verification, threat actors are able to:
Intercept legitimate update requests originating from WinGUp servers
Redirect traffic to malicious servers via Man-in-the-Middle (MitM) attacks or DNS cache poisoning
Deliver trojanized executables (disguised as update.exe) that appeared to be legitimate software patches
Leveraging this vulnerability, attackers have gained a persistent presence in high-value sectors. According to reports from Kaspersky, the impact has spanned government and telecommunications, critical infrastructure, and financial services.
How CVE-2025-15556 Works
The state-sponsored Lotus Blossom campaign was executed in three attack chains, between July and October 2025. Each phase evolved to evade detection by changing file sizes, IP addresses, and delivery methods.
Phase
Timeline (2025)
Execution Method
Payload
Chain #1
July – August
1MB NSIS installer (update.exe)
Multi-stage attack launching a Cobalt Strike beacon via ProShow.exe.
Chain #2
September
140KB NSIS installer (update.exe)
Rotated C2 URLs to maintain stealth while dropping a Cobalt Strike beacon.
Chain #3
October
Backdoor Deployment
Dropped BluetoothService.exe, log.DLL, and shellcode to establish the Chrysalis backdoor.
Mapping CVE-2025-15556 to MITRE ATT&CK
Flashpoint has mapped Lotus Blossom TTPs (tactics, tools, and procedures) to the MITRE ATT&CK framework. Flashpoint analysts have identified the following techniques:
M1057: Data Loss Prevention M1031: Network Intrusion Prevention
Protecting Against CVE-2025-15556
Proactive defense requires not only reactive patching of CVE-2025-15556, but also active threat hunting using the TTPs identified by Flashpoint analysts. Flashpoint recommends the following actions:
Immediate Update: Ensure all instances of Notepad ++ are updated to v8.9.1 or higher immediately. This version enforces the signature verification that was missing in previous releases.
Audit System Paths: Scan for malicious file paths used for persistence.
Network Defense: Monitor and block traffic to malicious domains.
Endpoint Hardening: Implement Behavior Prevention on Endpoints (M1040) and Audit (M1047) to detect unauthorized registry run keys or new system services.
Outpace Threat Actors Using Flashpoint
Software trust is only as strong as the infrastructure behind it. As organizations respond to these recent updates, having best-in-class vulnerability intelligence and direct visibility into threat actor TTPs is the best defense.
Login
Table Of Contents
