Software Security Effectiveness

Unlock the complete study guide + 1,040 practice questions across 16 full exams.

Bundled into the existing Certified Information Systems Security Professional premium course — no separate purchase.

Included in this chapter:

What "effectiveness" means: evidence, verification, validation
Auditing and logging of code and configuration changes
Software risk analysis, mitigation, and authorization (A&A)
Software security metrics and effectiveness measures
Exam-pattern recognition

Assessment vs. Authorization: who does what, and who owns the residual risk

Activity	What it produces	Who performs it	Decision / risk ownership
Assessment (formerly Certification, the Assess step)	Evidence: control-assessment findings, test/review results, recommendations: the Security Assessment Report (SAR)	An assessor independent of the system's developers/operators	Reports risk; does NOT accept it
Authorization (formerly Accreditation, the Authorize step)	An Authorization to Operate (ATO) and a documented residual-risk decision	A senior authorizing official (AO)	Explicitly ACCEPTS the residual risk on behalf of the organization
Plan of Action and Milestones (POA&M)	A running ledger of known, unresolved weaknesses with owners, resources, and due dates	System owner, maintained through Authorize and Monitor	Tracks risk being worked down; not an acceptance by itself
Continuous monitoring	Ongoing evidence that controls stay effective as code and config change	Operations / security team	Feeds the AO's ongoing authorization decision (reauthorize or revoke)

Cheat sheet

Assessing effectiveness means demanding objective evidence, not trusting "no incidents"
The authorizing official accepts residual risk, the assessor never does
C&A was modernized into A&A: certification became Assess, accreditation became Authorize
The Security Assessment Report (SAR) is the assessment deliverable that feeds the risk decision
Unresolved weaknesses are tracked on a POA&M, which is not itself a risk acceptance
A change must be approved by someone independent of the requestor
Emergency changes use an expedited path and are documented retroactively, never skipped
Effectiveness is only checkable if the change history is complete and tamper-evident
Security metrics must be risk-weighted, not raw counts
Defect density normalizes quality so you can compare components and releases
Vulnerability recurrence signals that a fix treated symptoms, not root cause
SSDF (SP 800-218) groups secure-development practices into PO, PS, PW, RV
A CVSS base score is severity, an input to prioritization, not the risk itself
Review and test coverage tells you how much your evidence actually speaks to
The assessor must be independent of the software's developers and operators
Mean time to remediate measures the fix pipeline's responsiveness, not just the find rate
A high SAST false-positive rate is a key weakness: it breeds alert fatigue and erodes developer trust
Use manual or peer secure code review for business-logic and authorization flaws that automated scanners miss
Verify configuration against a baseline with compliance checks; automate them with SCAP

Unlock with Premium — includes all practice exams and the complete study guide.

References

NIST glossary: verification Whitepaper
NIST SP 800-128: Security-Focused Configuration Management Whitepaper
NIST SP 800-92: Guide to Computer Security Log Management Whitepaper
NIST SP 800-37 Rev. 2: Risk Management Framework Whitepaper
NIST SP 800-53A Rev. 5: Assessing Security and Privacy Controls Whitepaper
NIST glossary: Authorization to Operate (ATO) Whitepaper
NIST glossary: accreditation Whitepaper
NIST glossary: Plan of Action and Milestones (POA&M) Whitepaper
NIST SP 800-218: Secure Software Development Framework (SSDF) Whitepaper
NIST SP 800-40 Rev. 4: Guide to Enterprise Patch Management Planning Whitepaper
NVD: CVSS (Vulnerability Metrics) Whitepaper