A vulnerability register linked to your assets, risks and controls

The vulnerability register

The register holds each known weakness, whether it came from a scanner, a dependency check, a vendor advisory or a penetration test report. Each entry carries the CVE identifier where there is one, the CVSS base and environmental scores, the assets affected and the remediation status.

Because the register sits in your GRC workspace, a vulnerability can be linked to the control it weakens, the risk it raises and the change needed to fix it.

• CVE details taken from the NVD
• CVSS base, temporal and environmental scores
• Affected assets from your asset register
• Severity, owner, due date and remediation status on each record

Advisories matched to the software you run

Certifyi checks the software and hardware in your asset inventory against the NVD using CPE identifiers. When a published vulnerability matches one of your assets, it appears in the register with the affected assets already linked.

Each match is also recorded as a risk, so it has an owner and a severity in the same workspace as your controls. Your team reviews each match and confirms whether the version you run is affected.

CPE identifier

The NVD names affected products with CPE identifiers, and matching compares them with the software recorded in your inventory.

Affected assets

Each match is linked to the assets it affects.

Risk record

Each match is recorded as a risk, with an owner and a severity.

From advisory to deployed patch

A vulnerability that needs a patch usually moves through identification, assessment, testing, deployment and verification in the tools your team already uses. Auditors expect a record of who approved the patch, when it was tested, the rollback procedure and whether the check after deployment passed.

ISO 27001 A.8.8 and SOC 2 CC7.1 both ask for evidence that patches are identified, assessed and applied in good time, and the patch record is that evidence. Attach it to the control it supports, where the tamper-evident activity log shows who added it and when.

Risk acceptance when a patch has to wait

Some vulnerabilities cannot be patched straight away. The vendor has no fix yet, the system is end-of-life, or the next change window is months off. A waiver records the risk, the compensating controls in place, an expiry date and the approver who signed it.

Waivers stay in the vulnerability register with their expiry date, instead of being forgotten in a spreadsheet. Auditors can see the decision and who made it.

Use the scanners you already run

Certifyi is not a scanner. It is the register where scanner output becomes tracked remediation inside your compliance programme.

• CrowdStrike and Microsoft Defender: endpoint and security findings through their connectors
• Other scanners: ask us which connectors are available for your tools

Findings go into the same register, linked by CVE and asset.

Vulnerabilities in the risk register

A critical vulnerability left unpatched is a risk, but in many organisations the vulnerability list and the risk register are separate spreadsheets. In Certifyi, a published vulnerability matched to one of your assets is linked to the risk register, with an owner, a severity and a remediation date.

A risk treatment that calls for patching can point back to the vulnerability record, so the risk owner can see how remediation is going.

Reporting for boards and auditors

Boards and auditors tend to ask the same questions about vulnerabilities: how many findings are open by severity, how old the oldest ones are, and which waivers are in force. Answer them from the register your security team works in, not from a separate spreadsheet.

Because each match is recorded as a risk, it appears in the risk register and its heatmap beside the rest of your risks, so the board and the engineers are looking at the same records.