8.3 Software Security Effectiveness
8.3 Software Security Effectiveness
Building security controls into software is not enough.
An organisation also needs evidence that those controls: are operating, can be trusted, address the relevant risk and produce the intended security outcome.
CISSP 8.3 focuses on assessing software-security effectiveness through two explicit areas: auditing and logging of changes, and risk analysis and mitigation.
The management question is no longer only: "Did we perform the security activity?"
It becomes: "Can we demonstrate that meaningful software risk is actually being reduced?"
Create Evidence
Record important software changes so actions can be reconstructed and attributed.
KNOW WHAT CHANGEDAssess the Risk
Understand threats, vulnerabilities, likelihood, impact and business context.
UNDERSTAND WHAT MATTERSProve Reduction
Verify that mitigations reduce risk rather than merely closing tickets.
SHOW THE CONTROL WORKSAssess the Effectiveness of Software Security
The current ISC2 CISSP Exam Outline explicitly lists only two subtopics.
Preserve useful evidence of security-relevant software, configuration, repository, pipeline and deployment changes.
Determine the actual risk created by software weaknesses and confirm that mitigation reduces that risk appropriately.
Official 8.3 Topics
Where 8.3 Fits
Integrate security throughout development.
WHEN?
Secure languages, libraries, tools, repositories, pipelines and AppSec testing.
WHERE & WITH WHAT?
Use evidence and risk analysis to determine whether security actually works.
DOES IT WORK?
Assess security impact of software and services obtained externally.
WHO BUILT IT?
Define and apply secure coding guidelines and standards.
HOW SHOULD CODE BE WRITTEN?
What Does "Effective" Software Security Mean?
A security control is effective when it produces the intended protection in the real context where the software operates.
Security Activity vs Security Effectiveness
| Activity Statement | Effectiveness Question |
|---|---|
| We scan every build. | Are the scans finding relevant weaknesses early enough to reduce risk? |
| Every developer receives training. | Are vulnerable coding patterns decreasing? |
| We log every deployment. | Can unauthorized or suspicious changes be identified and investigated? |
| We closed 500 findings. | Were the highest-risk weaknesses actually removed from production? |
| We require peer review. | Does the review process detect meaningful security defects and prevent unauthorized change? |
Effectiveness Memory Aid
Auditing vs Logging
Creates records of events and changes.
Examines evidence to determine whether activity was authorized, appropriate, complete and consistent with requirements.
The Change Audit Questions
Security-Relevant Changes Worth Auditing
Commits, merges, protected-branch changes and security-sensitive code modifications.
Permission changes, branch-rule changes, token creation and administrative actions.
New packages, removed packages, version upgrades and lock-file changes.
Compiler flags, build definitions, runners, signing settings and artifact-generation changes.
Changes to SAST, DAST, SCA, secret-scanning rules, policy gates and bypass mechanisms.
Pipeline definitions, environment protections, deployment logic and machine-identity permissions.
Which release was deployed, by whom or what automation, to which environment and with what result.
Security-sensitive application, container, platform, feature-flag and environment changes.
Creation, rotation, permission change or exceptional use of high-value credentials.
Expedited changes should still remain attributable and reviewable.
End-to-End Change Traceability
What Makes a Change Record Useful?
Record the accountable human, service account, workload identity or automation that performed the action.
Record when the event occurred using a reliable and consistent time source.
Describe what was attempted or completed.
Identify the repository, file, branch, pipeline, environment, component or configuration affected.
Record success, failure or other relevant outcome.
Where appropriate, link the action to approval, review, ticket or policy decision.
For important configuration changes, enough evidence should exist to understand how state changed.
Identifiers such as commit hashes, build IDs, artifact digests and deployment IDs support reconstruction.
Audit-Log Integrity
Audit evidence is useful only if investigators and reviewers can reasonably trust it.
Restrict who can alter or delete change evidence.
Where practical, avoid allowing the same identity to perform sensitive changes and silently rewrite the evidence.
Forward or aggregate relevant evidence so compromise of one development system does not automatically erase the full history.
A security-relevant system that stops producing expected logs should not fail silently.
Logs can contain source paths, tokens, user data or secrets and require access control themselves.
Keep records long enough to support investigation, assurance, contractual and legal requirements appropriate to the organisation.
🕒 Time Synchronization Matters Evidence must be placed in the correct sequence
Commit recorded at 10:03.
Build recorded at 09:58 because its clock is wrong.
Deployment recorded at 10:01.
"We Log Everything"
A development organisation collects: terabytes of repository, pipeline and deployment logs.
However:
Audit, Monitoring and Investigation
Create records.
Observe records and conditions for events that may require attention.
Review evidence against expected, authorized or required behaviour.
Reconstruct events and determine what happened when suspicious activity is identified.
Risk Analysis
A vulnerability is a technical weakness.
Risk analysis asks what that weakness means in the context of the actual software, threat environment and business impact.
Software Risk Factors
How important is the software, data or business process affected?
Who or what could exploit the weakness or cause the adverse event?
What weakness or predisposing condition enables the threat?
Is the vulnerable function Internet-facing, internal, isolated, authenticated or otherwise constrained?
How feasible is exploitation in the real environment?
How likely is the relevant harmful event given the current conditions?
What would happen to confidentiality, integrity, availability, safety, privacy, finances, legal obligations or reputation?
Which controls already reduce likelihood or impact?
Does the software support critical transactions, sensitive information or important customers?
Is the weakness actively exploited or especially relevant to current threat actors?
Technical Severity ≠ Business Risk
High technical severity.
Medium technical severity.
Inherent Risk vs Residual Risk
Risk considered before the effect of relevant controls.
Risk that remains after controls and mitigation are considered.
Risk Mitigation
Risk mitigation introduces controls or changes that reduce the likelihood, impact or both.
Patch, upgrade, rewrite or otherwise eliminate the weakness where practical.
Restrict network access, disable the vulnerable feature or require stronger authentication.
Reduce what an exploited component or account can access.
Introduce additional checks that prevent the vulnerable condition from being triggered.
Improve detection so exploitation can be identified and responded to more quickly.
Separate the vulnerable component or workload to limit attack paths and blast radius.
Use an alternative safeguard when the preferred control cannot be implemented immediately.
Move away from software that cannot be secured or maintained adequately.
Risk Mitigation Memory Aid
"The Developer Marked It Fixed"
A critical authorization vulnerability is assigned to the development team.
The ticket status changes to: RESOLVED.
No one verifies the production deployment or retests the vulnerable behaviour.
🛡️ Compensating Controls Reduce risk when the preferred fix cannot be implemented immediately
A legacy application contains a vulnerable component that cannot be upgraded until a vendor-supported release is available.
Temporary Mitigation Needs Governance
Who is accountable for the remaining risk?
Which systems and vulnerability conditions does the temporary control cover?
How will the organisation confirm the control is operating?
When will the risk and workaround be reassessed?
What permanent remediation will allow the temporary control to be removed?
What exposure remains even with the compensating control?
✍️ Adjacent Risk Concept - Acceptance Is Not Mitigation Useful CISSP distinction
Risk mitigation reduces the risk.
Risk acceptance means the appropriate accountable party knowingly decides to retain the residual risk.
Broader risk-response strategies are covered elsewhere in CISSP. In 8.3, keep the exam focus on analysing software risk and determining whether mitigation is effective.
Fix the Defect - Then Ask Why It Happened
Ten applications contain the same broken authorization pattern.
Metrics Can Help Assess Effectiveness
Metrics can provide evidence, but only when the measurement actually relates to the security objective.
Useful for understanding whether a security activity is being performed.
Useful for understanding whether the activity may be producing the intended result.
Useful Software-Security Measures
| Measure | What It Can Tell You | Important Caution |
|---|---|---|
| Security-testing coverage | How much of the relevant application estate receives the intended controls. | Coverage does not prove the tests are effective. |
| Mean / median remediation time | How quickly findings move toward remediation. | Averages can hide severe outliers. |
| Critical findings beyond SLA | Whether important weaknesses remain unresolved. | SLA age alone does not equal business risk. |
| Production escape rate | How often meaningful defects evade pre-production controls. | Requires consistent definitions and detection capability. |
| Recurring weakness rate | Whether root-cause improvements are reducing repeated defect patterns. | Taxonomy and coverage must be consistent. |
| False-positive rate | Whether automated controls produce usable signal. | Very low noise does not prove high detection coverage. |
| Security gate bypasses | Whether exceptions and overrides are becoming normal behaviour. | Some legitimate emergency exceptions may exist. |
| Residual high-risk items | How much significant accepted or outstanding software risk remains. | Requires consistent risk analysis. |
The Dashboard Looks Better - Security Got Worse
Last quarter: 1,000 vulnerabilities.
This quarter: 200 vulnerabilities.
Management celebrates an 80% improvement.
But the reason is: security scanning coverage dropped from 95% of applications to 20%.
Good Metric Questions
Turn Evidence Into Improvement
Effectiveness Hierarchy
A control can exist and operate yet still fail to achieve its security objective.
🧠 45 CISSP Practice Scenarios Audit evidence, risk analysis and mitigation
A company says its secure-development programme is effective because every application runs SAST once before release.
What is missing?
Evidence that the activity actually reduces relevant software risk and is performed at the right time, with useful coverage and remediation.
A dashboard shows 10,000 security scans completed this quarter.
What does this primarily measure?
Activity or effort, not necessarily security effectiveness.
The number of critical exploitable application vulnerabilities reaching production falls significantly after a new control is introduced.
What type of evidence is this?
Outcome-oriented evidence that may support an effectiveness assessment.
A repository records who changed a security-sensitive authentication module, when it changed, the commit, reviewer and associated ticket.
Which official 8.3 topic?
Auditing and logging of changes.
A production configuration is modified, but there is no record of who made the change.
Primary weakness?
Accountability and change traceability are insufficient.
A change log records that a file changed but not the user, time or previous value.
Is the audit trail strong?
No. The record lacks important context needed to reconstruct and assess the change.
An administrator can edit both production configuration and the audit records that document the edit.
Primary concern?
The trustworthiness and integrity of the audit trail are weakened.
Developers can delete repository history without detection.
Which property is especially important?
Audit-log integrity and protection from unauthorized modification.
Build servers, repositories and deployment systems use clocks that differ by several hours.
Why does this matter?
Inconsistent timestamps can make event correlation and reconstruction unreliable.
A change record shows the code commit but cannot link it to the build artifact deployed to production.
What is missing?
End-to-end traceability from source change through build and deployment.
A security-sensitive dependency is upgraded, but dependency changes are not included in audit records.
Better approach?
Include material dependency and software-composition changes in the change evidence where appropriate.
A CI/CD administrator disables SAST for one release and reenables it afterwards. No audit event is generated.
Primary risk?
A critical security-control change can occur without accountability or detection.
A log exists for every deployment, but nobody reviews it and no alert is generated for unusual changes.
What does this demonstrate?
Logging alone does not guarantee effective auditing or monitoring.
An audit review finds repeated emergency production changes with no post-implementation review.
What should management do?
Investigate the control weakness and improve the change process rather than treating each record as an isolated event.
A developer introduces an unauthorized change directly in production. Repository history is clean, but deployment and runtime configuration logs show the change.
Why are multiple log sources valuable?
They can provide complementary evidence and expose changes that bypass the normal source-control path.
A security control is documented in policy but there is no evidence it is implemented.
Is policy existence enough?
No. Effectiveness requires evidence that the control is implemented and operating as intended.
A control is implemented exactly as designed but does not reduce the relevant threat because the design assumption was wrong.
What does this show?
Implementation correctness does not automatically prove control effectiveness.
A team fixes a vulnerability but never retests the application.
What important step is missing?
Validate that the mitigation actually addressed the weakness and did not create unacceptable new risk.
A critical vulnerability is patched, but the vulnerable service remains reachable because the patch was not deployed to one production cluster.
What does this show?
Remediation completion should be verified in the real target environment.
A vulnerability has a high technical severity but exists only in an isolated non-production utility with no sensitive data.
CISSP approach?
Assess actual risk using context rather than treating technical severity alone as business risk.
A medium-severity authorization flaw allows a customer to access another customer's financial records.
What should drive prioritization?
Business impact, exploitability and exposure can make the actual risk high despite the label.
A threat can exploit a vulnerability easily, but the affected asset has minimal business impact.
Which risk factors matter?
Both likelihood and impact must be considered.
A catastrophic impact is possible, but exploitation requires an extremely unlikely set of conditions.
What should risk analysis consider?
Likelihood as well as impact.
A vulnerability exists, but an effective compensating control substantially reduces the chance of exploitation.
Which concept?
Residual risk after existing controls.
A team reports risk before considering any existing controls.
Which concept?
Inherent or pre-control risk.
After mitigation, some risk remains.
Is this normal?
Yes. Controls often reduce rather than eliminate risk; the remaining exposure is residual risk.
Management wants to know whether to fix a finding immediately, schedule it, apply a compensating control or formally accept the residual risk.
What is required first?
Risk analysis using relevant business and technical context.
A mitigation reduces the likelihood of exploit but slightly increases operational complexity.
What should be assessed?
The overall residual risk and trade-offs, including whether the mitigation introduces new risk.
A web application vulnerability is mitigated by removing the vulnerable feature entirely.
What type of mitigation?
Eliminating the exposed condition can remove or greatly reduce the relevant risk.
A vulnerable legacy component cannot be patched immediately, so network restrictions and stronger monitoring are added temporarily.
Which concept?
Compensating controls that reduce risk while permanent remediation is pending.
A compensating control is added but nobody assigns an expiry or review date.
What is the concern?
Temporary mitigation can silently become permanent without reassessment.
The security team closes findings whenever developers mark them 'fixed' in the ticketing system.
Better practice?
Use evidence or retesting appropriate to the risk before concluding the mitigation is effective.
A mitigation resolves the original flaw but breaks authentication for legitimate users.
What lesson?
Security effectiveness includes verifying that mitigation works without creating unacceptable functional or operational consequences.
The same vulnerability pattern reappears in ten applications after each individual defect is patched.
Best mature response?
Address the systemic development-process cause in addition to individual findings.
A team measures average remediation time, but severe exploitable findings and informational findings are combined into one number.
Why can this metric mislead?
Aggregation can hide risk; metrics should preserve meaningful context such as severity, exploitability and business importance.
A security programme proudly reports that vulnerability counts increased after coverage expanded from 20% to 95% of applications.
Does the increase prove security got worse?
No. Better visibility and broader coverage can increase discovered findings even while the programme improves.
A programme reports fewer findings because teams stopped scanning high-risk systems.
Does the metric prove improvement?
No. A favourable number can reflect reduced measurement rather than reduced risk.
Developers begin suppressing legitimate findings because their performance target is 'zero open vulnerabilities'.
What problem?
A poorly designed metric can create harmful incentives and distort behaviour.
Management wants a useful effectiveness indicator for secure development.
Which is generally stronger?
A balanced set of measures linking coverage, control operation, remediation and risk outcomes rather than a single vanity metric.
An application-security control produces many alerts, but almost none lead to confirmed risk or remediation.
What should be assessed?
Signal quality and whether the control is providing useful security value.
Incidents involving the same software weakness continue after secure-coding training was introduced.
What should management infer?
Training activity alone does not prove effectiveness; evaluate whether behaviour and outcomes changed.
A serious production incident reveals that a known risk was accepted by the correct business owner with documented rationale and review date.
Is this risk mitigation?
No. It is risk acceptance; 8.3 specifically includes risk analysis and mitigation, while acceptance is a broader risk-response option.
Which two sub-bullets are explicitly listed under current CISSP 8.3?
Answer?
Auditing and logging of changes; Risk analysis and mitigation.
What is the strongest evidence that a security mitigation is effective?
Best answer?
Appropriate verification shows that the targeted risk was actually reduced to an acceptable residual level.
Management asks for the central purpose of CISSP 8.3.
Best answer?
Use trustworthy change evidence and risk analysis to determine whether software-security controls and mitigations are actually reducing meaningful risk.
Recognise the Clue Words
Who Changed It?
Accountability for modification.
Audit TrailWhat Changed?
Before/after or affected item.
Change LoggingWhen Did It Change?
Sequence and reconstruction.
TimestampTicket → Commit → Build → Deploy
End-to-end evidence.
TraceabilityLog Exists but Nobody Reviews
Data without assurance.
Logging ≠ AuditingLogs Can Be Altered
Evidence can be falsified.
Audit IntegrityDifferent System Clocks
Events cannot be reliably ordered.
Time SynchronizationControl Exists on Paper
No operating evidence.
Not Proven EffectiveThreat + Vulnerability
Potential exploitation path.
Risk AnalysisLikelihood + Impact
Core risk factors.
RiskBefore Controls
Untreated exposure.
Inherent RiskAfter Controls
Remaining exposure.
Residual RiskSeverity Score Only
Technical signal lacks business context.
Severity ≠ RiskTemporary Alternative Control
Reduce exposure while fix waits.
Compensating ControlFix Applied
Do not assume success.
Retest / VerifySame Defect Repeats
Systemic weakness.
Root Cause ImprovementScans Completed
Activity measurement.
Effort MetricProduction Vulnerabilities Falling
Security outcome.
Result / Outcome MetricGood Number, Less Coverage
Metric can mislead.
Measurement BiasZero Findings
May reflect weak detection.
Not Proof of Security⚠️ Common CISSP Mistakes Activity, evidence and risk are not the same thing
Logging creates records. Auditing examines evidence to determine whether activity was authorized, appropriate and consistent with requirements.
Operational debugging data can be useful, but change auditing requires records that support accountability and reconstruction of material changes.
Large volumes of low-value data can make important evidence harder to identify.
Audit evidence should be protected against unauthorized modification and deletion.
Consistent time sources improve correlation across repositories, pipelines, hosts and deployment systems.
Production configuration, pipeline settings, infrastructure, dependencies and privileged runtime changes may occur outside ordinary source history.
A documented requirement is not evidence that the control operates as intended.
A correctly implemented control can still be ineffective against the actual risk.
Counting scans, reviews or training sessions measures work performed, not necessarily risk reduction.
Counts ignore asset value, exploitability, exposure, impact and control context.
Technical severity is one input. Business context can raise or lower actual priority.
Likelihood also matters.
Impact also matters.
Controls frequently reduce risk rather than removing it completely.
Some risk can remain after effective mitigation and may still be acceptable to the accountable risk owner.
Evidence or retesting appropriate to the risk should confirm that remediation is effective.
Administrative status does not prove the vulnerable condition is gone from the relevant environment.
Temporary alternatives should be monitored, reassessed and replaced where a permanent fix is required.
Acceptance acknowledges residual risk; mitigation reduces likelihood or impact.
A balanced view is usually needed because individual metrics can be gamed or misinterpreted.
The number may fall because coverage, detection capability or reporting declined.
Improved coverage can reveal more previously unknown weaknesses.
Averages can hide critical outliers and important differences in exploitability and business impact.
8.2 applies controls in the development ecosystem and performs AppSec testing. 8.3 assesses whether software security and mitigation are effective.
8.3 applies risk analysis and mitigation specifically in the software-security effectiveness context; broader enterprise risk concepts are covered elsewhere too.
Quick Reference
| If you see... | Think... |
|---|---|
| Who changed what, when and why? | Auditing / Change Logging |
| Ticket → commit → build → artifact → deploy | Traceability |
| Audit record can be edited | Integrity Problem |
| Events cannot be ordered across systems | Time Synchronization |
| Logs generated but never examined | Logging Without Effective Audit |
| Control documented but not evidenced | Not Proven Effective |
| Threat + vulnerability + likelihood + impact | Risk Analysis |
| Risk before controls | Inherent Risk |
| Risk after controls | Residual Risk |
| Technical score without business context | Severity ≠ Risk |
| Reduce likelihood or impact | Risk Mitigation |
| Temporary alternative safeguard | Compensating Control |
| Developer marks finding fixed | Verify / Retest |
| Same flaw keeps returning | Root Cause / Systemic Improvement |
| Number of scans completed | Effort / Activity Metric |
| Reduction in exploitable production flaws | Outcome / Result Metric |
| Fewer findings because less scanning | Misleading Metric |
| Metric drives suppression behaviour | Perverse Incentive |
| Risk formally accepted by owner | Acceptance, Not Mitigation |
| Does the control actually reduce risk? | Effectiveness |
8.3 Master Memory Aid
Evidence → Risk → Mitigation → Verification → Improvement
The Software Security Leader's 8.3 Questions
Key Takeaways
CISSP 8.3 is: Assess the effectiveness of software security.
The current ISC2 outline explicitly lists only two subtopics: auditing and logging of changes, and risk analysis and mitigation.
The central 8.3 question is: can the organisation demonstrate that its software-security activities are actually reducing meaningful risk?
Security activity and security effectiveness are not the same.
Running a scanner, completing a review, delivering training or creating a log proves that an activity occurred.
It does not automatically prove that the intended security outcome was achieved.
Effectiveness requires evidence.
Useful change evidence can help answer: who changed what, when, where, why, with whose approval and with what result.
Logging creates records.
Auditing reviews evidence to determine whether activity was authorized, appropriate, complete and consistent with expected controls.
Therefore: logging ≠ auditing.
Important software-security change evidence can come from source repositories, dependency management, build systems, security-tool configuration, CI/CD pipelines, deployment platforms and runtime configuration.
Repository history alone may not provide the entire change history.
A privileged production configuration change may bypass ordinary source control.
End-to-end traceability can connect: business need → ticket → commit → review → build → security test → artifact → deployment.
This helps demonstrate that the production software is the version that was expected, authorized and tested.
Audit evidence should itself be protected.
If a privileged user can make an unauthorized change and erase all evidence of it, accountability is weak.
Audit-log access, integrity, retention and availability should be appropriate to the value of the evidence.
Logging failures can also matter.
A critical development or deployment system that unexpectedly stops producing audit evidence should not necessarily fail silently.
Time synchronization improves correlation.
Repository, build, deployment and runtime events are easier to reconstruct when their clocks use consistent reliable time.
High log volume does not equal strong auditing.
Evidence should be relevant, reviewable, trustworthy and usable.
Risk analysis converts technical findings into business-relevant security decisions.
A vulnerability is a weakness.
Risk depends on context including the threat, likelihood, impact, exposure, business importance and existing controls.
Therefore: vulnerability severity ≠ business risk.
A high technical score in an isolated low-value system may have different priority from a medium technical weakness that enables unauthorized access to financial data.
CISSP expects risk-based judgement rather than blind sorting by one technical number.
Likelihood and impact are both important.
High impact with negligible likelihood is not automatically equivalent to high likelihood with severe impact.
Existing controls affect risk.
Inherent risk describes risk before considering relevant controls.
Residual risk is what remains after the effect of controls and mitigation.
Effective mitigation does not necessarily reduce risk to zero.
Risk mitigation reduces likelihood, impact or both.
Mitigation can include patching, upgrading, removing vulnerable functionality, restricting exposure, reducing privileges, adding validation, isolating components, strengthening monitoring or replacing insecure technology.
Compensating controls can reduce risk when the preferred permanent fix cannot be implemented immediately.
But: "we cannot patch it" is not itself a compensating control.
Temporary mitigations should have ownership, defined scope, evidence of operation and appropriate reassessment.
Risk acceptance is different from mitigation.
Acceptance means the accountable party knowingly retains residual risk.
Mitigation changes the risk by reducing it.
A mitigation is not proven effective merely because a developer marks the finding resolved.
Verification or retesting appropriate to the risk should confirm that the vulnerable condition has actually changed.
The assessment should also consider whether the mitigation created new security, operational or functional risk.
A closed ticket is not necessarily a closed risk.
The real question is whether the vulnerable condition remains in the relevant environment and what residual risk is left.
Repeated defects can indicate ineffective systemic controls.
If the same weakness appears across many applications, the mature response is not only to patch each instance.
The organisation should investigate the development-process root cause and improve requirements, design patterns, frameworks, coding guidance, testing or review as appropriate.
Metrics can support 8.3 effectiveness assessments.
But metrics are supporting concepts, not additional current ISC2 8.3 sub-bullets.
Effort metrics measure activity, such as scans run, reviews completed or applications onboarded.
Result or outcome metrics attempt to measure what happened because of the security effort, such as production vulnerability escape rates or recurrence of known weakness patterns.
Activity metrics can be useful.
But: activity ≠ outcome.
Vulnerability counts should also be interpreted carefully.
More findings can result from improved coverage.
Fewer findings can result from reduced testing.
Therefore: more findings ≠ automatically worse security, and fewer findings ≠ automatically better security.
Good measures preserve context.
They should help decision-makers understand risk, coverage, trends, control operation and improvement.
Poor metrics can create perverse incentives.
A target of "zero open vulnerabilities" may encourage teams to suppress findings, redefine severity or avoid scanning instead of reducing risk.
Measure what supports the intended security decision rather than what produces the most attractive dashboard.
The mature effectiveness cycle is:
collect evidence → assess risk → apply mitigation → verify the result → reassess residual risk → improve the process.
Remember the Domain 8 boundaries:
8.1 = integrate security through the lifecycle.
8.2 = secure the development ecosystem and perform AppSec testing.
8.3 = assess whether software security is effective.
8.4 = assess the security impact of acquired software.
8.5 = define and apply secure coding guidelines and standards.
The central CISSP principle for 8.3 is:
do not confuse the existence of a security control with evidence that it works. Preserve trustworthy change evidence, analyse the real software risk, mitigate it appropriately and verify that the residual risk has actually been reduced.
📚 Sources & Further Reading Authoritative references for auditing, risk and software-security effectiveness
- ISC2 - CISSP Certification Exam Outline
View the current CISSP Exam Outline - NIST SP 800-53 Rev. 5 Update 1 - Security and Privacy Controls for Information Systems and Organizations
View NIST SP 800-53 - NIST SP 800-30 Rev. 1 - Guide for Conducting Risk Assessments
View NIST risk-assessment guidance - NIST Risk Management Framework
View the NIST Risk Management Framework - NIST SP 800-218 - Secure Software Development Framework (SSDF) Version 1.1
View NIST SSDF - NIST SP 800-92 - Guide to Computer Security Log Management
View the current final NIST SP 800-92 - NIST SP 800-92 Rev. 1 - Cybersecurity Log Management Planning Guide - Initial Public Draft
View the current revision draft - OWASP SAMM - Strategy and Metrics
View OWASP SAMM Strategy and Metrics - OWASP SAMM - Measure and Improve
View OWASP SAMM measurement guidance - OWASP SAMM - Metrics and Feedback
View OWASP SAMM defect metrics and feedback