Vulnerability Management and Secure Development
Vulnerability Management and Secure Development tests risk-based prioritization and controls embedded in the software lifecycle. GCT-2A-324 expects you to know why CVSS alone is insufficient, how EPSS and CISA KEV change priority, and how SAST, DAST, SCA, and secrets scanning fit different stages of development.
Core rules and concepts
- Maintain an asset inventory and scan authenticated where possible. Unauthenticated scans miss local packages and misconfiguration; false positives and false negatives both require validation.
- CVSS measures technical severity, not organizational risk. EPSS estimates the probability of exploitation in the wild; CISA KEV lists exploited vulnerabilities. Combine severity, exposure, exploitability, business impact, and compensating controls.
- Patch SLAs should be risk-tiered. If patching is delayed, document compensating controls, ownership, and an expiry date.
- Secure SDLC controls include threat modeling during design, SAST for source code, SCA for dependencies, DAST against running applications, secrets scanning, and CI/CD gates. SBOMs in SPDX or CycloneDX improve dependency visibility.
- Hardcoded secrets must be removed and rotated; deleting the commit is not enough because history and forks may retain the value.
Worked example
Two findings arrive: CVSS 9.8 in an internal development tool with no internet exposure, and CVSS 7.5 in an internet-facing VPN appliance that appears in CISA KEV. The second is prioritized despite the lower base score because it is exposed, known-exploited, and on the perimeter. The team applies the vendor patch within the emergency SLA, enables temporary mitigations, and verifies with an authenticated rescan. The internal finding is scheduled in the normal cycle after confirming the tool is not reachable from user networks. The reasoning: exploitability and exposure outweigh a severity score in isolation.
Traps that cost marks
- Prioritizing by CVSS alone and ignoring KEV, EPSS, exposure, and business context.
- Scanning without an owner, remediation workflow, or verification rescan.
- Treating an SBOM as proof of security rather than a visibility artifact.
- Assuming a passed SAST scan means the application is free of vulnerabilities.