Free Certified Secure Software Lifecycle Professional (CSSLP) practice test: 30 questions with answers

Isolation or compartmentalisation contains the damage from a compromised component. Shared global state, hard-coded trust and unchecked single entry points increase damage.

A threat model identifies threats early so controls can be designed in. It does not replace code review, prove the absence of vulnerabilities, or replace the architecture.

Encrypting sensitive fields with keys held separately limits the value of a stolen database. Keys stored with the data or unencrypted data offer little protection.

Fail secure means a failure denies access or stops safely. Granting rights, skipping logs and broadcasting errors all weaken security during failure.

Parameterised queries keep user input separate from SQL, which directly prevents injection. Stripping characters is fragile, and the other options do not address the root cause.

Standard, reviewed libraries are far less likely to contain subtle flaws than custom cryptography. The other statements are not accurate reasons.

Bounded functions that check destination size prevent overflow. The gets function is unsafe and removing checks or only enlarging buffers does not remove the risk.

Secure code review finds security defects before release. Elegance, line counts and ownership changes are not its main purpose.

Least privilege limits each account to the minimum rights its role requires. Defense in depth, separation of duties and security through obscurity are other principles with different aims.

Confidentiality guards against unauthorised disclosure. Changes to data describe integrity, loss of access describes availability, and denial of origin describes non-repudiation.

A vulnerability is the weakness itself. A threat actor is the attacker, a countermeasure is a control, and an audit is a review process.

Residual risk is what remains after controls. Inherent risk is before controls, transferred risk moves to others, and accepted risk is a decision to keep a risk, which may or may not be residual.

White-box testing uses internal knowledge. Black-box testing uses external behaviour only, and penetration and acceptance testing have different focuses.

Fuzz testing reveals crashes and memory errors from malformed input that attackers could also trigger. Layout, load and documentation checks are different activities.

Dynamic testing of a running application finds injection flaws and can confirm configuration issues. Line lists, commit counts and account totals are not dynamic test results.

A security test case attempts the unauthorised action and checks it is denied. Usability, performance and localisation tests measure different qualities.

Security functional requirements state required secure behaviour. Performance, usability and cost statements are not security requirements.

Traceability shows each requirement addresses a real risk and can be verified. Length, ignoring requirements and separate sales are not reasons for traceability.

Abuse cases describe misuse and the protections needed. Normal use cases, user stories and burndown charts do not focus on misuse.

Laws and regulations are a standard source of security requirements for personal data. Colour preferences, page counts and timelines do not define security needs.

Planning should define security roles and the activities each release needs. Coding, deployment and data deletion belong to later or unrelated activities.

A maturity model provides a structured way to assess and improve practices. No model guarantees zero vulnerabilities, and models do not replace testing or set prices.

The business or risk owner accepts residual risk for the organisation. Developers, external testers and end users do not hold that decision.

A threat model and risk register record security decisions and risks across the lifecycle. Brochures, first-release notes and user manuals do not serve that role.

Prompt patching and monitoring keep a deployed system secure. Never changing it, disabling logs and permanent broad access all weaken operations.

A configuration baseline is an approved secure state that deployed systems are checked against for drift. Colours, user limits and vendor lists are unrelated.

Testing in a representative environment checks for regressions before production. Simultaneous rollout, skipping change records and waiting for exploitation all add risk.

An SBOM lists the components, versions and sources of a product. Licence prices, authors and hardware locations are not in an SBOM.

Verifying a signature or hash against a trusted source detects tampering. Unknown shares, renaming and elevated installs do not verify anything.

Dependency confusion occurs when a public package with an internal name is pulled in by mistake. Licence removal, disk space and documentation lapses are different issues.