Your
Trusted
Get Fully AWS Funded
Cloud Migration
Cloud Migration
A CVE is an identifier for a publicly disclosed security vulnerability. It helps teams find and share information about the affected product and investigate available fixes.
Vulnerability management covers finding, assessing, treating and tracking weaknesses. Patch management focuses on obtaining, testing, deploying and verifying updates, including security patches.
A high Base score indicates technical severity. Urgency also depends on whether the affected software is present, how it is exposed, evidence of exploitation and the possible impact on the organisation.
The team can assess temporary protections, such as limiting access, while monitoring the vendor’s guidance. It should record the decision, the person responsible and a date to review the remaining risk.
Depending on the issue, the team can check the deployed version, run relevant tests, confirm service health and rescan the affected resource. The checks and their results should be recorded.
A security alert lands in your inbox. It says that a library used by your application has a critical vulnerability. You have a CVE number, a severity score and a link to the advisory. What should your team do next?
First, find out where the library is used. Then check whether the affected version is running, how it can be reached and who can make the change. Once the team applies a fix, it needs to confirm that the right systems are updated and the application still works.
This is vulnerability management in practice. It gives a team a way to turn security information into a clear decision and follow that decision through to a verified result.
The amount of information involved keeps growing. 263% more CVE submissions were recorded between 2020 and 2025. For an engineering team, the practical challenge is finding the issues that affect its own systems and making time to address them.
A CVE is a reference number for a publicly disclosed security vulnerability. It gives software vendors, security teams and developers a common way to identify and discuss a specific problem.
The CVE Program publishes records that describe these vulnerabilities and point to supporting information. A record can help you find the affected product and versions, then follow the vendor’s advice on available fixes.
Imagine your company uses a payment application that depends on a software library. A CVE is published for that library. Your team checks the installed version and discovers it is affected. The next question is whether the vulnerable feature can be reached in your application and what the impact could be.
A CVE tells you what to investigate. The investigation tells you what it means for your environment.
Software companies rely on many moving parts: application code, open-source libraries, container images, servers and cloud services. Each has its own updates and ownership. A vulnerability in any one of those components can affect a service or expose data if the conditions for exploitation are present.
A vulnerability management process helps a team keep track of those components, assess findings, decide what to fix and record the outcome. It also makes responsibilities clearer when a security team finds an issue but another team owns the application.
Log4Shell is a useful example. The vulnerability affected Log4j, a library used by many applications and products. Teams needed to find where it was present, including in indirect dependencies, and then apply and check the relevant fixes. CISA guidance recommended keeping an inventory of affected systems and verifying the action taken.
A severity score helps a team understand the technical characteristics of a vulnerability. The decision about urgency also needs information about the system where the vulnerability appears.
For example, imagine the same vulnerable library is found in two places. One copy runs in a customer-facing service. The other is in an isolated test environment. The team should examine both findings, yet the exposed service may need attention sooner because an attacker has a clearer path to it and the potential impact is greater.
The CVSS Base score is one input to that assessment. Base scores “should not be used alone to assess risk.” Teams also need to consider the software in use, network access, existing protections and business impact.
Threat information can help. The CISA KEV catalog identifies vulnerabilities with confirmed exploitation. EPSS estimates the likelihood that exploitation activity for a vulnerability will be observed across its data partners in the next 30 days. Neither tells you on its own whether your particular system has been compromised.
Priorities can change. A finding may become more urgent when a service is exposed to the internet, new exploit information appears or another affected production system is discovered.
A useful first step is to give the finding an owner and record what is known: the affected system and version, the reason for the priority, the planned action and any open questions. This gives the people involved a shared place to follow progress.
Some fixes are straightforward. An application team may be able to update a library to a compatible version, run its tests and deploy the change. Other updates need more preparation because they affect dependencies, require a maintenance window or introduce changes to the application.
If a fix is not yet available, the team may be able to reduce exposure temporarily. For example, it might restrict network access to an affected service while it waits for a vendor update. The decision should include a responsible owner and a review date, so the remaining risk stays visible.
After deployment, the team checks the result. Depending on the finding, this can mean confirming the version running in production, testing the application, checking service health and rescanning the affected resource. A completed ticket is easier to trust when it points to the evidence behind the decision. For container workloads, image digests can help teams identify the artifact running in production.
A patch management program gives teams a way to obtain, test, deploy and verify software updates. Some updates introduce features or fix ordinary bugs. Others address security vulnerabilities.
Patching is a “critical component of preventive maintenance” for technology, and patch management guidance includes verifying that updates have been installed.
The connection is practical. Vulnerability management helps identify and assess the risk. Patch management provides a process for applying the update when a patch is the right treatment. If an update could interrupt a service, teams need to plan testing, approval and rollback before the change.
Different tools look at different parts of an environment. Some scan servers or container images. Others identify vulnerable application dependencies. Their findings can help a team see what needs investigation and keep track of progress.
For AWS workloads, Amazon Inspector assesses supported resources for known software vulnerabilities and unintended network exposure. Its findings can provide details about affected resources and support further investigation.
For dependencies, reachability analysis looks for paths from application code to vulnerable functions. That information can help a team decide which alerts to investigate first, together with severity, exposure and knowledge of the application.
A tool is most useful when the team knows what it covers and has agreed what happens after an alert. Someone still needs to review the finding, own the decision and check that the action worked.
Cloud security work depends on understanding the environment around each change. Architecture, monitoring and operational ownership all affect how a team investigates and resolves an issue.
AWS managed services bring these areas together to help teams operate their cloud infrastructure. The scope and responsibilities depend on the work agreed with each customer.
The guide to AWS Security Hub migration illustrates the importance of checking the result of a security change. It describes how teams can validate findings, alerts and reporting when moving between security standards.
For a software team, the goal is a process people can follow: understand the finding, decide who acts, make the change safely and keep enough evidence to know what happened.