Severity
Technical characteristics and potential impact.
VULNERABILITY MANAGEMENT
Finding vulnerabilities is the start. Knowing which ones to fix first is management.
Corporate infrastructures continually change. New assets, applications, versions, services and vulnerabilities emerge while the environment needs to continue operating.
In this scenario, generating a list of vulnerabilities is not enough.
Add Solution structures Vulnerability Management programs to identify exposures, contextualize risk, establish remediation priorities and continuously validate whether the actions taken have actually reduced the attack surface.
SEVERITYEXPOSUREASSET
RISK / PRIORITY
REMEDIATEREVALIDATEEVOLVE
ENGENHARIA APLICADA
Prioridade nasce da combinação entre severidade, exposição e impacto.
A Add Solution organiza descoberta, contexto, priorização, tratamento e revalidação para transformar achados técnicos em redução mensurável de risco.
Arquitetura, execução e operação tratadas como partes da mesma responsabilidade.
A VULNERABILITY IS MORE THAN JUST A CVE
The identifier describes the vulnerability. The environment determines its context.
CVE, severity, asset, exposure, criticality, exploitability and existing controls need to be related.
Exposure
Internal and external scope and existing controls.
Asset
Function, owner and criticality.
Exploitability
Evidence and exploitation conditions.
Business
Affected process and dependencies.
Two companies may have the same vulnerability and completely different remediation priorities.
We cannot evaluate what we do not know exists.
Servers, workstations, network devices, firewalls, appliances, applications, cloud assets, services, and unknown assets make up the attack surface according to scope.
Vulnerability management begins before the scanner. It begins with understanding the technology landscape.AI & Observability
An IP address alone offers little context.
Hostname, type, system, owner, logical location, service, environment, criticality, exposure, and business function help guide prioritization.
Prioritizing vulnerabilities also requires understanding the assets where they exist.
The goal of scanning is not to produce as many findings as possible.
Network scanning, authenticated scanning, agents, cloud integrations and platform assessments can produce evidence depending on the solution and environment.
The goal is to obtain sufficiently reliable evidence to guide a decision.
Observing an asset from the outside and assessing it from the inside can provide different levels of visibility.
Packages, patches, configurations, software, and versions can become visible when supported. The credentials used must be protected; authentication does not eliminate false positives.
PAM & Identity SecurityTechnical severity is important. Business priority requires more context.
CVE identifies a publicly known vulnerability. CVSS represents its characteristics and severity, but does not determine operational priority by itself.
CVSS + EXPLOITABILITY + EXPOSURE + ASSET CRITICALITY + BUSINESS CONTEXT → PRIORITY
A score helps assess severity. Context helps determine priority.
Not every vulnerability has the same likelihood of being exploited.
Exploit availability, evidence of exploitation, threat intelligence, exposure, preconditions and complexity can enrich the analysis depending on the sources, without accurately predicting attacks.
A vulnerability accessible via the Internet has a different context than the same vulnerability isolated internally.
Internet-facing assets, internal networks, segmentation, firewalls, ACLs, VPN, ZTNA, reachability, and published services change the analysis—without making internal assets risk-free.
Network Security & FirewallThe same finding has different impacts depending on where it is.
Critical servers and workstations, production and development environments, infrastructure, and business applications have different confidentiality, integrity, and availability requirements.
A vulnerability belongs to an asset. The asset belongs to a business process.
RISK-BASED PRIORITIZATION
Fixing everything immediately is not a strategy. Prioritizing correctly is.
SEVERITY × EXPOSURE × EXPLOITABILITY × CRITICALITY × CONTEXT → PRIORITY
The methodology depends on the program, organization and tools, with no universal formula.
The remediation queue should represent risk, not just a score.
Before mobilizing a team, we need to trust the evidence.
Version, service, configuration, context, evidence, and manual verification when necessary increase confidence without completely eliminating false positives.
Automation provides scale. Validation adds confidence.
Severity describes the vulnerability. Intelligence adds external context.
Exploited vulnerabilities, known activity, and campaign context can enrich prioritization based on available sources, without providing absolute prediction.
REMEDIATION
Detecting a vulnerability does not reduce risk until action is taken.
A patch is not the only possible response. Treatment must consider technology, operations, and the formal risk process.
01Patch
02Upgrade
03Configuration change
04Hardening
05Remove service
06Segment
07Restrict access
08Compensating control
09Accept risk
Vulnerability management and patch management are not synonymous.
Vulnerability Management identifies and prioritizes risk. Patch Management implements some of the fixes through updates when applicable.
Not every vulnerability has a patch. Not every patch has the same priority.
Not all exposure is related to outdated software.
Services, protocols, configurations, administrative interfaces, permissions, defaults, ciphers and access controls also need to be evaluated.
When immediate correction is not possible, reducing exposure may still be necessary.
Firewall, WAF, segmentation, ACL, IPS, ZTNA, isolation, disabling and access restriction can mitigate depending on the scenario.
Mitigating risk does not mean considering the vulnerability fixed.Application & Web Security
No exception should simply disappear from management.
Justification, owner, risk, compensating control, approval, deadline, review, and evidence maintain accountability.
Accepted risk remains known risk and must have a review cycle.
Closing a ticket does not prove that the vulnerability no longer exists.
FINDING → REMEDIATION → RESCAN → VALIDATION → CLOSED / REOPENED
Remediation ends when the fix is validated, not when the activity is marked complete.
When the same problem returns, the cause may be in the process.
Golden images, templates, automation, configuration, deployment, patching, and baselines can reproduce findings.
Remediating a vulnerability resolves one finding. Addressing the cause can prevent hundreds of them.
Software, systems, services and workloads require their own context.
Workstations, servers, packages, patches, configurations, and inventory connect Vulnerability Management to EDR/XDR and infrastructure.
Endpoint Security (EDR/XDR) Servers & storageSwitches, firewalls, access points, and appliances are also part of the attack surface.
Firmware, software, services, management interfaces, protocols and configurations require infrastructure analysis.
Corporate NetworksIn the cloud, software vulnerability and security configuration can coexist.
VMs, images, workloads, packages, services, exposure and cloud context need to be considered without reducing the program to CSPM.
CloudInfrastructure and application may require different methodologies.
There is overlap, but an infrastructure scanner does not automatically replace DAST, SAST, or pentesting.
Application & Web SecurityASSESSMENT ≠ PENTEST
Finding vulnerabilities at scale and simulating attack paths are related but different activities.
Assessment provides systematic discovery, scale, recurrence, and prioritization. Pentesting provides targeted assessment, controlled validation, attack chains, and impact analysis according to scope.
Vulnerability Management seeks continuity. Pentesting provides targeted depth.
Priority must result in a deadline and accountability.
Risk, criticality, exposure, and organizational policy guide internal deadlines; there is no universal SLA.
CRITICAL → SHORTEST DEADLINE · HIGH → CONTROLLED DEADLINE · MEDIUM → PLANNED CYCLE · LOW → BACKLOG
Counting vulnerabilities is easy. Measuring risk reduction is more useful.
Risk distribution, age, remediation time, SLA, recurrence, coverage, critical exposure, and reopened findings provide useful information for technical, management, and executive audiences.
Closing a thousand vulnerabilities means little if the ten most important ones remain open.
CONTINUOUS CYCLE
The environment changes every day. The assessment from six months ago describes another environment.
DISCOVER → ASSESS → PRIORITIZE → REMEDIATE → VALIDATE → MEASURE → REPEAT
Vulnerability Management is not a periodic scan. It is a continuous process.
MATURITY ASSESSMENT
Does your process end in the scanner report or does it prove risk reduction?
We assess process, coverage, context, ownership, treatment, and measurement to structure meaningful improvement.
01Inventory
02Coverage
03Scanning
04Credentials
05Findings
06Prioritization
07Asset context
08SLAs
09Ownership
10Remediation
11Exceptions
12Revalidation
13Metrics
14Integrations
ADD SOLUTION METHOD
Findings turned into a measurable reduction in exposure.
More than 15 years of experience connecting networking, firewall, servers, endpoint, cloud, applications, PAM, observability and operations.
- 01
Discover
Assets and technological surface.
- 02
Identify
Vulnerabilities and evidence.
- 03
Validate
Confirm the finding and its context.
- 04
Contextualise
Relate assets, exposure and business.
- 05
Prioritise
Direct effort based on risk.
- 06
Treat
Correct, mitigate or formally accept.
- 07
Revalidate
Verify the result.
- 08
Measure
Track reduction and recurrence.
- 09
Evolve
Continuously improve the program.
The scanner finds vulnerabilities. Engineering turns findings into priorities and priorities into measurable exposure reduction.
TECHNOLOGIES & PRODUCTS
Process, engineering, prioritization, remediation and validation.
The tool is one component of the program. Vendors appear on product-specific technology pages.
Cybersecurity Technologies & ProductsPERGUNTAS FREQUENTES
Decisões importantes sobre Gerenciamento de Vulnerabilidades
Respostas objetivas para dúvidas técnicas e operacionais que costumam surgir antes de um projeto.
01CVSS determina sozinho o que deve ser corrigido primeiro?
Não. Severidade técnica precisa ser combinada com exposição, exploitability, criticidade do ativo e contexto do negócio.
02Vulnerability Management é o mesmo que patch management?
Não. A gestão identifica e prioriza risco; patch management executa parte das correções quando atualizações são aplicáveis.
03Vulnerability assessment substitui pentest?
Não. Assessment oferece descoberta sistemática e recorrente; pentest realiza avaliação direcionada e validação controlada conforme escopo.
04Fechar um chamado significa que a vulnerabilidade foi corrigida?
Não necessariamente. Revalidação ou rescan precisa confirmar se a exposição deixou de existir.
05Mitigação equivale a correção definitiva?
Não. Controles compensatórios podem reduzir exposição, mas a vulnerabilidade continua exigindo gestão e revisão.
FALE COM UM ESPECIALISTA
Vamos conversar sobre Gerenciamento de Vulnerabilidades.
Share the context of your environment, the perceived impacts and the results your organization seeks. Add Solution will direct the conversation to the most appropriate experts.
CONTEXTO DA CONVERSAGerenciamento de VulnerabilidadesOrigem e interesse são registrados automaticamente no atendimento.