A published advisory assigns an identifier to a known flaw in the firmware version running on the city's VPN concentrators. How should the security team track that flaw?
Select an answer to reveal the explanation.
Short Explanation
CVE IDs are the shared license-plate numbers for known bugs. When the VPN box has a published flaw, tag work and scans with that CVE so everyone is fixing the same thing—not a homemade nickname.
Full Explanation
Public vulnerability advisories commonly assign CVE identifiers so organizations can correlate scanners, patches, and reports on the same known flaw. When an advisory names a flaw in firmware on the city’s VPN concentrators, the security team should record and track the issue using that CVE identifier. Shared identifiers keep municipal ticketing, vendor bulletins, and scan tools aligned.
Inventing only a local ticket number and never mapping it to the public identifier fragments correlation. Treating the advisory as marketing and omitting it from vulnerability records leaves remote-access infrastructure untracked. Renaming the flaw after the mayor does not help interoperability with industry tooling.
Exam caveat: CVE is the standard tracking key for known vulnerabilities; vendor bug IDs may also be recorded but should map to CVE when one exists. Not every issue has a CVE yet—track vendor IDs until assignment.
Operational check: open a vuln ticket keyed by CVE, link vendor advisory and affected concentrator inventory, schedule firmware remediation, and verify scans clear that CVE after upgrade. Include CVE IDs in status reports to city security stakeholders.
When firmware on VPN concentrators is upgraded, retain before/after version strings beside the CVE ID in the ticket so municipal auditors can trace advisory → asset → fix without reconstructing the story from chat logs.