Select Two (Multi-Select) Questions

Granting 'Admin' privileges to all developers on the CI/CD server.

Why it fails: Admin rights on the CI/CD server let any developer alter pipeline definitions, credentials and build agents, defeating segregation of duties. It is tempting because broad access removes friction when engineers need to debug failed builds, and least privilege is the actual control required.

Storing pipeline secrets in plain text within the Jenkinsfile.

Why it fails: Plain-text secrets in a Jenkinsfile are readable by anyone with repository access and persist in commit history. It is tempting because inline values are the quickest way to get a pipeline running, whereas a secrets manager injects credentials at runtime without storing them in source.

The annual maintenance budget

Why it fails: Abuse cases model attacker goals and misuse scenarios against a system, so they derive from threat intelligence and attacker behaviour, not finance. A maintenance budget is tempting because it constrains security spending, but it belongs to cost planning, not abuse-case development.

Developer performance metrics

Why it fails: Abuse cases derive from attacker goals, threat intelligence and misuse scenarios, not from how well developers perform. Developer metrics are tempting because they feed process improvement and capacity planning, and would be relevant to retrospectives or estimation, not to modelling adversarial behaviour.

The internal office floor plan

Why it fails: Abuse cases require attacker-centric inputs such as threat models and misuse scenarios; a floor plan describes physical layout and reveals nothing about adversarial goals or system misuse. It is tempting because physical security reviews use building layouts, so it would be correct for assessing perimeter or facility access controls.

Changing the application's CSS file.

Why it fails: CSS files govern presentation only and cannot influence authentication logic, session handling or access control decisions. It is tempting because styling changes are easy to inject and can hide interface elements, which resembles UI redress; genuine bypass testing targets credential validation, session tokens and authorisation checks instead.

Testing the application's color scheme.

Why it fails: Colour scheme is a visual design attribute with no bearing on authentication enforcement, so it cannot reveal a bypass. It is tempting because interface manipulation tests do form part of security assessment, and misleading visuals can support phishing; authentication bypass testing instead examines credential checks, session management and privilege boundaries.

Hardcoding API keys in the code for efficiency.

Why it fails: Hardcoded keys ship inside the artefact, so anyone with the binary or repository can extract them, collapsing authentication to a single static secret with no rotation or revocation. It is tempting because it removes runtime configuration work, and secrets managers or environment injection are the correct choice when deployment convenience is the goal.

Relying solely on the WAF for security.

Why it fails: Defense in depth requires controls at multiple layers.

Elevation of Privilege.

Why it fails: Elevation of Privilege concerns gaining higher permissions, countered by authorisation checks and least privilege, not signing. Digital signatures address Tampering and Repudiation, so selecting this threat misattributes the control's mechanism, even though signatures are correctly used for integrity assurance.

Information Disclosure.

Why it fails: Digital signatures provide integrity and authenticity, not confidentiality; they cannot prevent data being read. Information Disclosure is countered by encryption in transit and at rest, making signatures the wrong control here despite their genuine role in defeating tampering and repudiation.

Denial of Service.

Why it fails: STRIDE's Denial of Service concerns resource exhaustion and availability, which digital signatures cannot address; they provide integrity and non-repudiation, not availability. It is tempting because signatures do authenticate message origin, so candidates conflate that with blocking floods, but throttling, rate limiting or WAF rules are the actual DoS mitigations.

Automating the password recovery workflow.

Why it fails: Password recovery is an account-management workflow, not an authentication test element; automating it tests process orchestration rather than whether the API correctly validates credentials and rejects forged or expired tokens. It is tempting because recovery touches credentials, but the correct elements are authentication mechanism, credential handling and negative authorisation checks.

Testing the speed of the API response.

Why it fails: Response speed measures performance, not authentication security, so it cannot verify that credentials, tokens or claims are validated correctly. It is tempting because latency testing belongs in API non-functional test suites, and would be the right choice for a performance test case rather than one covering secure authentication.

Using stored procedures with dynamic SQL

Why it fails: Stored procedures containing dynamic SQL still concatenate untrusted input into statements, so injection remains possible. It is tempting because stored procedures are often cited as a defence, but that only holds when they use parameterised queries rather than dynamically built SQL strings.

Relying solely on client-side validation

Why it fails: Client-side validation runs in the browser and is trivially bypassed by crafting requests directly to the server, so it cannot prevent injection. It is tempting because it improves user experience and catches malformed input early, but server-side parameterised queries are what actually block the attack.

The full password of the user involved in the event.

Why it fails: Logging full passwords exposes credentials to anyone reading the audit trail, directly undermining the account security the log exists to evidence. It is tempting because authentication events are auditable, but the correct practice records the username, timestamp and outcome, never the secret itself, which must remain unrecoverable from logs.

The user's home address and phone number.

Why it fails: Home address and phone number are personal data irrelevant to reconstructing who performed which action and when, so they add privacy risk without audit value. It is tempting because user identity matters in audit trails, but the correct entries are the account identifier, event timestamp and action performed, not contact details.

Allowing multiple simultaneous sessions for a single user.

Why it fails: Permitting concurrent sessions for one account multiplies the tokens an attacker can steal or hijack and complicates revocation. It is tempting because users legitimately work across several devices, but secure session management favours single active sessions or explicit concurrent-session limits with monitoring.

Using long-lived sessions to improve user experience.

Why it fails: Long-lived sessions widen the window in which a stolen token remains valid, and they cannot be revoked promptly after logout or privilege change. It is tempting because persistent sessions reduce re-authentication friction, but secure session management requires bounded lifetimes with idle and absolute timeouts.

Storing session tokens in the browser's local storage.

Why it fails: Local storage is readable by any JavaScript on the page, so a single cross-site scripting flaw exposes the token. It is tempting because local storage persists across tabs and survives refreshes, but tokens belong in HttpOnly, Secure cookies that scripts cannot read.

Share all internal server IP addresses in the public DNS records.

Why it fails: Publishing internal server IP addresses in public DNS exposes the application's internal topology to attackers, enabling direct targeting and bypassing perimeter controls. DNS records exist to resolve names to addresses for legitimate clients, so public records suit internet-facing services only. Internal addressing belongs in split-horizon or private zones, never in publicly resolvable records.

Permit all inbound traffic on port 80 to ensure maximum availability.

Why it fails: Permitting all inbound port 80 traffic removes filtering, so monitoring cannot detect or block malicious requests. It is tempting when availability is prioritised, but a web application firewall with logging would be the correct monitoring control.

Disable all egress traffic from the application servers to prevent data exfiltration.

Why it fails: Disabling all egress traffic breaks the application's legitimate outbound dependencies, such as database replication, API calls and patch downloads, so it cannot function. It is tempting because egress filtering genuinely blocks command-and-control and exfiltration channels, and would suit a strictly isolated, no-outbound-connectivity workload rather than a normal operational application.

The speed of software development is too slow.

Why it fails: Slow development speed is an outcome of poor process integration, not a challenge inherent to adopting a Secure SDLC; the recognised challenges are things like developer resistance, tooling integration and scaling security training. It is tempting because security gates can add friction, but the question asks about implementation challenges, not symptoms of an already-failing process.

Having too much budget for security tools.

Why it fails: Excess budget is not a recognised challenge; Secure SDLC adoption typically suffers from constrained funding, competing priorities and unclear ownership. It is tempting because abundant tooling can create sprawl, yet the stem asks for common organisational challenges, and over-funding security is not one of them.

Eliminates the need for penetration testing

Why it fails: Early requirements inform threat modelling and reduce costly rework, but penetration testing still validates deployed controls against real attack paths. Requirements define expected behaviour; they cannot substitute for adversarial testing. The option appeals because shift-left reduces vulnerabilities reaching production, yet assurance testing remains a distinct activity.

Reduces the amount of documentation required

Why it fails: Early security requirements typically increase documentation through threat models, abuse cases and compliance traceability; they do not reduce it. It is tempting because shifting left can cut rework, and it would be valid if the goal were fewer late-stage defect fixes rather than less paperwork.

Allows for the removal of all security testing

Why it fails: Security requirements shape design and reduce defect cost, but testing remains mandatory to verify controls operate as intended. The option confuses early requirement definition with test elimination; requirements cannot replace dynamic verification. It tempts because shifting security left reduces remediation effort, yet static and dynamic testing still apply.

Encrypting data at rest using AES.

Why it fails: AES encryption at rest provides confidentiality by rendering data unreadable without the key; it does not detect or prevent unauthorised alteration, which is integrity's concern. It is tempting because encryption is a common security control, and it would be correct where the requirement is protecting stored data from disclosure.

Ensuring the server is always online.

Why it fails: Availability, not integrity, is what keeping a server online preserves; integrity concerns unauthorised modification of data or code. It is tempting because uptime genuinely matters in resilience planning, and an always-online server would be the right answer to an availability question.

Forcing users to change passwords regularly.

Why it fails: Forcing password changes supports confidentiality and authentication by limiting credential exposure, not integrity, which concerns preventing unauthorised modification of data or code. It is tempting as a general security control, but integrity is maintained through hashing, checksums, digital signatures and access controls.

Trust but verify

Why it fails: 'Trust but verify' assumes an initial trust decision before checks occur, which contradicts Zero Trust's premise that no actor or device is trusted by default regardless of network location. It is tempting because it sounds security-conscious, but it belongs to perimeter-based models; Zero Trust requires explicit verification of every request before access is granted.

Trust all internal network traffic

Why it fails: Trusting all internal network traffic treats the corporate network as an implicit trust boundary, which is exactly the assumption Zero Trust rejects. It is tempting because internal traffic was historically considered safe behind the firewall, but Zero Trust requires every request to be authenticated and authorised regardless of origin, internal or external.

Outsourcing all security tasks to third-party vendors.

Why it fails: Outsourcing every security task removes internal accountability and oversight, which governance frameworks require the organisation itself to retain. It is tempting because vendors supply specialist tooling and expertise, and selective outsourcing of penetration testing or monitoring is valid when the organisation still owns risk decisions.

Mandating that all developers become certified hackers.

Why it fails: Requiring developer certification in offensive tooling addresses none of the policy, risk, or compliance controls governance demands, and it narrows the talent pool. It is tempting because security awareness training genuinely strengthens governance, and offensive skills are correct for dedicated red-team roles rather than all developers.

Discontinuing all legacy applications.

Why it fails: Retiring all legacy applications ignores business continuity, data migration, and risk-based prioritisation that governance mandates. It is tempting because legacy systems often carry unpatched vulnerabilities, and decommissioning is correct for a specific end-of-life application once its replacement and data retention are assured.

Hardware procurement

Why it fails: Hardware procurement concerns acquiring physical infrastructure, which sits outside the SSDLC's process scope of requirements, design, implementation, verification and release. It tempts because development environments need hardware, but procurement is an operational prerequisite, not a security activity embedded in the lifecycle itself.

Marketing strategies

Why it fails: Marketing strategies shape product positioning and demand, not secure software construction, so they contribute nothing to threat modelling, secure coding or verification activities within an SSDLC. The option tempts because commercial viability genuinely matters to product success, but that belongs to business planning, not the security engineering lifecycle.

Unlimited project budget

Why it fails: Budget size does not determine whether security activities such as risk assessment, secure design or code review occur; an SSDLC is defined by its processes, not its funding level. It tempts because security tooling and training do cost money, yet adequate resourcing is an enabler rather than an essential lifecycle component.

Keeping the API endpoint documentation private.

Why it fails: Hiding API documentation relies on obscurity rather than publishing design for review, which Open Design demands. It tempts because limiting attacker reconnaissance appears prudent, but private documentation would be correct under a defence-in-depth posture that prioritises concealment over transparent, scrutinised design.

Hiding the source code from all development team members.

Why it fails: Concealing source code from developers contradicts Open Design, which requires public scrutiny of security mechanisms rather than secrecy. It is tempting because hiding code feels protective, and secrecy is genuinely correct for credentials or keys, but Kerckhoffs's principle demands the design itself remain open to review.

Using a proprietary, secret encryption algorithm.

Why it fails: Secret proprietary algorithms contradict Open Design, which requires security mechanisms to withstand scrutiny without relying on obscurity. It tempts because secrecy feels protective, but closed algorithms are the correct choice only where threat models accept Kerckhoffs's principle being violated, which Open Design rejects.

Auto-scaling of the registry's storage capacity.

Why it fails: Auto-scaling storage addresses capacity and availability, not supply chain attack prevention; the registry instead needs signature verification, immutable versioning and provenance attestation. It is tempting because scaling is a genuine registry concern, but only for performance scenarios, not for blocking tampered or malicious artifacts.

Automatic translation of code into multiple languages.

Why it fails: Translation of code into multiple languages has no bearing on supply chain integrity; registries must verify provenance, sign artifacts and scan dependencies. It is tempting because localisation pipelines are legitimate DevOps tasks, but they belong in build tooling, not in an artifact registry's security controls.

Disabling all automated deployment pipelines.

Why it fails: Disabling pipelines removes the automated, repeatable enforcement that keeps environments consistent, so drift increases as manual changes accumulate. It is tempting because pipelines can propagate a bad configuration, but the correct drift-reduction scenario is controlled, versioned pipeline deployment with approvals, not abandoning automation.

Allowing manual configuration changes via the SSH console.

Why it fails: Manual SSH changes bypass version control and review, so each host diverges from the declared baseline and drift grows. It is tempting because direct console access helps urgent break-fix work, but it is the correct choice only in an incident-response context, not as a standing configuration management practice.

Embed hardcoded credentials for the database in the build artifact to ensure connectivity.

Why it fails: Hardcoded database credentials inside the artefact leak to anyone who obtains the build, cannot be rotated without rebuilding, and violate secrets-management requirements. Injecting credentials at runtime from a vault or environment configuration is the correct approach; embedding suits only isolated local test fixtures with non-production data.

Bypass unit tests to speed up the deployment pipeline.

Why it fails: Skipping unit tests removes the verification gate that catches regressions and security-relevant defects before artefacts ship, so the build cannot be trusted as production-ready. It tempts teams chasing faster pipelines, and would suit throwaway prototypes or local development builds where no release approval or integrity evidence is required.

Compile the code with debugging symbols enabled for easier production troubleshooting.

Why it fails: Debug symbols expose internal function names, paths and memory layout in the shipped binary, giving attackers reconnaissance material and enlarging the artefact. They are genuinely useful for diagnosing crashes in pre-production or staging environments, but production builds should be stripped or symbols stored separately.