Hard Difficulty Questions

Cross-Site Request Forgery (CSRF).

Why it fails: CSRF exploits a browser's automatic inclusion of ambient credentials such as cookies, not forged token signatures. The 'alg: none' flaw lets an attacker submit an unsigned JWT that the verifier accepts, bypassing signature validation entirely to forge arbitrary claims. CSRF defences would be the right control when sessions rely on cookies without anti-forgery tokens.

Broken object-level authorization.

Why it fails: Broken object-level authorization concerns whether a user may access a specific object, assuming their identity is already established. The 'alg: none' attack subverts that establishment by letting an unsigned token assert any identity or role, so authentication is bypassed before authorisation is reached. Object-level checks are the right control when identities are trustworthy but per-object access rules are missing.

Insecure cookie flags.

Why it fails: The alg:none attack lets an attacker forge unsigned tokens, so signature verification is the critical flaw; cookie flags govern transport and storage, not token authenticity. Cookie flags are tempting because JWTs are often stored in cookies, but insecure flags do not enable alg:none forgery.

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.

Increased network latency.

Why it fails: Latency is governed by network topology, connection pooling and query execution, none of which a shared service account alters. It is tempting because consolidating access sounds like a bottleneck, but connection multiplexing is a separate concern; the real risk is loss of per-service accountability and non-repudiation in audit trails.

Increased risk of SQL injection.

Why it fails: SQL injection stems from unsanitised input reaching query parsers, not from credential sharing; a shared account changes attribution and blast radius, not query construction. It is tempting because shared credentials widen access, but injection is mitigated by parameterised queries and input validation, which this design choice does not affect.

Incompatibility with container orchestrators.

Why it fails: Container orchestrators authenticate workloads through service accounts, secrets or workload identity, so a shared credential remains technically usable. It is tempting because orchestrators favour per-workload identity, but incompatibility is not the risk; the actual issue is that revocation or rotation affects every microservice simultaneously, and audit logs cannot attribute actions.

Enable TLS mutual authentication (mTLS) between the sender and the message queue and between the queue and the receiver.

Why it fails: mTLS authenticates the endpoints and encrypts data in transit, but it does not protect the message after it is written to the queue. If an attacker gains access to the queue storage or an internal service, they could modify the message without breaking mTLS. End-to-end integrity requires a control that travels with the payload, such as a signature.

Encrypt the message payload with a symmetric key shared between the sender and receiver before placing it on the queue.

Why it fails: Symmetric encryption provides confidentiality but not integrity. An attacker who can modify the ciphertext might cause predictable changes or, if the encryption mode lacks authentication, could alter the plaintext without detection. Without a message authentication code or digital signature, the receiver cannot verify that the payload was not changed.

Use a message authentication code (MAC) with a key shared between all services that interact with the queue.

Why it fails: A MAC with a shared key can provide integrity, but if the key is shared among all services, any service can generate a valid MAC for a modified message. This does not provide non-repudiation and weakens the trust model. In a payment system, a shared symmetric key across many services increases the risk of key compromise and does not bind the message to a specific sender.

Implementing automated DAST tools.

Why it fails: DAST exercises a running application, so it detects flaws only after deployment, too late for the early lifecycle stage Shift-Left demands. It is tempting because DAST finds runtime and configuration issues that static analysis cannot, and would be correct once a deployed test environment exists.

Deploying a Web Application Firewall (WAF) to protect the current environment.

Why it fails: A WAF filters live HTTP traffic at runtime, so it mitigates attacks post-deployment rather than embedding security into earlier lifecycle phases. It is tempting because WAFs give immediate protection for exposed production applications, and would be correct when defending an already-running system against web attacks.

Performing a manual code review on all legacy source code.

Why it fails: Manual review of all legacy source code cannot scale to a waterfall codebase and delays feedback until after development, defeating Shift-Left's early, incremental detection. It is tempting because static human review finds logic flaws automation misses, and would suit a small, high-assurance codebase needing deep manual inspection.

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.

Centralized database user management.

Why it fails: Centralised database user management stores credentials in one repository but does not decouple authentication from each microservice, which still queries the database directly. It is tempting because it consolidates accounts; it would be correct for a single monolithic application sharing one database, not for distributed services.

Service Mesh with mutual TLS enabled.

Why it fails: A service mesh with mTLS encrypts and authenticates service-to-service connections, but authentication of end users remains per-service unless an external authorisation component is added. It is tempting because meshes centralise transport policy; it would be correct for zero-trust service identity, not centralised user authentication.

Sidecar pattern using a local proxy for mTLS.

Why it fails: A sidecar proxy secures service-to-service traffic with mTLS but leaves authentication logic distributed, since each service still validates tokens itself. It is tempting because sidecars do offload transport security; it would be correct for encrypting pod-level communication, not for centralising authentication decisions.

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.

Set the Content-Type header to application/json

Why it fails: Content-Type describes the request body's media type; it is client-controlled and carries no server-issued secret, so a forged cross-site request can set application/json just as easily. It is tempting because JSON endpoints often reject form-encoded posts, and would be correct for content negotiation or blocking simple form-based CSRF vectors, not for token validation.

Use a stateless session strategy with no tokens

Why it fails: A stateless session strategy removes the server-side session cookie, but CSRF exploits ambient credentials such as cookies or HTTP Basic authentication, so dropping sessions alone leaves state-changing endpoints unprotected. It is tempting because stateless APIs are common; the correct configuration enables Spring Security's CSRF token validation for those requests.

Enable csrf().disable() in the SecurityFilterChain

Why it fails: Disabling CSRF removes Spring Security's synchroniser token filter, so state-changing requests are accepted without any token validation — the opposite of prevention. It is tempting because it stops 403 errors during API development, and would be correct for a stateless REST API authenticated solely by bearer tokens, where no session cookie exists to forge.

Functional requirement

Why it fails: Encryption of service-to-service traffic is a quality attribute constraining how the system behaves, not a function it performs, so it belongs to non-functional requirements. Functional requirements are tempting because they describe system behaviour, but they specify what the system does, not the security constraint on how it does it.

Business rule

Why it fails: A business rule governs organisational policy or domain logic, not a technical security constraint on communication channels. Business rules are tempting because they also capture mandatory constraints, but they express operational policy decisions rather than the encryption quality attribute this requirement imposes on the architecture.

Use case description

Why it fails: A use case description documents actor interactions and expected system flows, not a cross-cutting security constraint. Use cases are tempting because they capture requirements in structured form, but they describe functional behaviour sequences, whereas encryption of service traffic is a non-functional quality attribute.

Storing secret keys as environment variables in the container spec.

Why it fails: Environment variables are readable by any process in the container and often leak into logs or crash dumps, so compromise exposes the keys. This is tempting for simplicity, and would be correct only where a dedicated secrets manager with short-lived, dynamically injected credentials is unavailable.

Running the application process as the root user.

Why it fails: Root inside the container allows a breakout to escalate to host-level privileges, magnifying the compromise's impact. Running as root is tempting because it avoids permission errors during image builds, and would be correct only in throwaway build stages, never for the running application process.

Using a single large image for all microservices.

Why it fails: A single shared image means one compromised container's vulnerability propagates to every microservice built from it, widening blast radius. Image reuse is tempting for consistency and faster builds, and would be correct where services genuinely share identical runtime dependencies and each container is otherwise isolated.

Role-Based Access Control (RBAC)

Why it fails: RBAC is a general model, not specific to Clark-Wilson's integrity enforcement.

Attribute-Based Access Control (ABAC)

Why it fails: ABAC uses attributes, which is a different access model.

Discretionary Access Control (DAC)

Why it fails: Clark-Wilson is more rigid than DAC.

Security Labels

Why it fails: Labels are used in Bell-LaPadula.

null

Why it fails: null

The Snyk token has expired.

Why it fails: An expired token would prevent the scan from starting at all.

The scan speed is set to 'High'.

Why it fails: Scan speed has no impact on build status.

The dependencies are already updated.

Why it fails: Updating dependencies should improve build status.

Disabling the 'Plugin' set for OS detection.

Why it fails: OS detection is irrelevant to the web interface scan.

Enabling 'Safe Checks' in the policy settings.

Why it fails: Safe checks prevent the scanner from performing actions that might crash the target.

Configuring the 'Port Scanner' to only scan port 80.

Why it fails: Management interfaces often run on custom ports.

null

Why it fails: null

Implement multi-party authorization

Why it fails: Multi-party authorisation governs approval workflows for privileged actions; it neither validates a cryptographic module nor addresses FIPS 140-3 conformance testing. It is tempting because separation-of-duties controls appear in secure government deployments, and it would be correct where dual-control approval of key operations is the stated requirement.

Develop custom encryption algorithms

Why it fails: FIPS 140-3 validates standardised, approved algorithms; custom cryptography cannot be certified and would fail validation outright. It tempts because bespoke algorithms appear to offer unique protection, yet the standard requires NIST-approved modules such as AES and SHA-2.

Encrypt all databases at rest

Why it fails: Database encryption at rest is a data-protection control, not evidence of FIPS 140-3 validation of the cryptographic module itself. It is tempting because FIPS-approved algorithms often underpin such encryption, and it would be correct where the requirement is protecting stored data rather than certifying the module.

Storing secrets in a configuration file within the deployment container.

Why it fails: Configuration files inside the container are copied into images and exposed through environment variables, logs and image layers, so secrets leak. It is tempting because externalised configuration is the right pattern for non-sensitive settings such as feature flags or endpoint URLs, where no confidentiality requirement applies.

Requesting secrets from the user at application startup.

Why it fails: Prompting the user at startup places secrets in memory, terminals and process listings, and prevents unattended restarts. It is tempting because it removes secrets from code and disk entirely, and would suit a locally run interactive tool where a human is always present to supply credentials.

Hard-coding secrets in the source code as encrypted strings.

Why it fails: Encrypted strings in source code still ship the decryption key alongside the ciphertext, and the repository retains the secret permanently. It is tempting because encryption appears to protect the value, and this approach would be acceptable for non-secret constants that merely need obfuscation, not confidentiality.

The vendor provides a generic privacy policy.

Why it fails: A generic privacy policy addresses data handling at the provider level, not the fourth-party risk of its subprocessors and their controls. It tempts because privacy documentation is a legitimate due-diligence artefact, but it evidences nothing about downstream supplier assessment or monitoring.

The vendor only uses software developed internally.

Why it fails: Internal-only development does not evidence fourth-party oversight; mature VRM requires assessing and monitoring the vendor's own suppliers and subprocessors. It tempts because reducing external dependencies genuinely lowers supply chain exposure, but it answers a different question than fourth-party risk management.

The vendor uses a public cloud provider.

Why it fails: Using a public cloud provider says nothing about how the vendor identifies, assesses, or monitors its own subprocessors, which is what fourth-party risk demands. It tempts because cloud hosting is a real supply chain dependency, but the practice itself is not evidence of VRM maturity.

Checking the file size

Why it fails: Checking file size limits resource consumption but does not inspect content, so a small malicious file still executes; the defence must validate type and content. It is tempting because size limits are a legitimate control against denial-of-service and storage exhaustion, and would be correct when the threat is oversized uploads rather than executable payloads.

Validating the file extension only

Why it fails: Extension validation relies on a client-supplied name that an attacker can rename, so a .php payload sent as .jpg passes; content and type verification is required. It is tempting because extension allow-lists are a standard upload control, and would be correct if filenames could be trusted and the web server never executed renamed files.

Enabling execution permissions on the upload folder

Why it fails: Granting execute permission on the upload directory lets any uploaded script run server-side, directly enabling the RCE the question asks you to prevent. It is tempting because some architectures do execute uploaded binaries deliberately, such as plugin or job-processing directories, but those require strict validation and isolation rather than open execution.

null

Why it fails: null

The DAST scanner is conflicting with the IAST agent.

Why it fails: While they can run together, they typically operate independently.

The source code repository is not accessible to the agent.

Why it fails: IAST works at runtime, not through static source access.

The build server lacks sufficient CPU cores for runtime instrumentation.

Why it fails: Resource constraints cause latency, not false positives.