Secure Software Lifecycle Management practice questions

Implementation.

Why it fails: Implementation focuses on actual security controls like build and deployment.

Verification.

Why it fails: Verification focuses on testing and auditing the software.

Operations.

Why it fails: Operations deals with security during the maintenance and deployment phase.

Increasing the frequency of manual code uploads.

Why it fails: Manual uploads bypass automated build provenance, commit signing and reproducible pipeline controls, weakening supply-chain integrity. It is tempting because manual steps feel controlled, and manual artefact handling would be correct for isolated, air-gapped releases where no CI system exists.

Using only open-source libraries without vetting.

Why it fails: Unvetted open-source libraries can introduce malicious or vulnerable dependencies, so integrity requires scanning, pinning and provenance checks. It is tempting because open source accelerates delivery, and unvetted use would be correct only in throwaway prototypes with no production or customer data exposure.

Ensuring all developers have root access to production.

Why it fails: Root production access removes least-privilege separation, letting any developer alter deployed artefacts and undermining supply-chain integrity. It is tempting because broad access speeds troubleshooting, and elevated access would be correct for a break-glass account with just-in-time approval and full auditing.

Elevation of Privilege.

Why it fails: Elevation of Privilege describes gaining rights beyond those granted, such as exploiting a flaw to become administrator. Passive sniffing grants no additional permissions by itself. This category would apply if the attacker escalated from a standard user to root through a vulnerability.

Tampering.

Why it fails: Tampering covers modification of data in transit or at rest, not passive interception. Sniffing alters nothing, so no integrity violation occurs. Tampering would fit an attacker rewriting requests or database records. The stem's eavesdropping on client-server traffic maps to Information Disclosure instead.

Spoofing.

Why it fails: Spoofing concerns impersonating a legitimate identity, such as forging credentials or a source address. Sniffing does not assume another party's identity; it silently observes. Spoofing would be correct if the attacker impersonated the web server or client to gain trust, not merely captured packets.

System Architecture Diagram.

Why it fails: An architecture diagram depicts components, data flows and trust boundaries for one system, not the organisation's high-level security expectations across all projects. It is tempting because it is a governance-adjacent artefact reviewed during design, and it would be the correct reference when assessing where encryption or authentication controls sit in a specific solution.

Individual Sprint Backlog.

Why it fails: A sprint backlog lists the tasks a team commits to for one iteration, so it cannot express organisation-wide security expectations. It is tempting because it is a familiar Agile artefact that every project maintains, and it would be the right place to track the remediation work items arising from a security review.

Developer Coding Standards.

Why it fails: Coding standards specify language-level rules such as input validation and banned functions, operating below the governance layer the question asks for. They are tempting because they are security documents every project follows, and they would be the correct reference when a developer needs concrete secure-coding rules for a specific language.

Writing a custom shell script to grep all files for common regex patterns.

Why it fails: A shell script scanning for regex patterns only catches secrets already written to disk, after the commit exists, and misses encoded or unfamiliar formats. It is tempting because custom pattern matching suits bespoke, one-off audits of legacy repositories. GitHub's native secret scanning with push protection blocks the commit before it reaches the remote, which the stem requires.

Relying on developers to manually check for secrets before every push.

Why it fails: Manual checking depends on human vigilance at each push, so a single lapse commits the secret into Git history, where it persists even after deletion. It is tempting because peer review and pre-push checklists genuinely suit low-volume, non-automated workflows, yet GitHub Actions supports automated scanning such as secret scanning and push protection that blocks the commit itself.

Configuring an external firewall to block all traffic containing API keys.

Why it fails: An external firewall cannot inspect developer commits before they reach the repository, so secrets still land in Git history. Firewalls filter network traffic at the perimeter, which suits blocking outbound exfiltration to known malicious hosts, not preventing credentials entering source control. Pre-commit hooks and push protection scan content at commit time instead.

Storing artifacts in a public S3 bucket for easy access.

Why it fails: A public S3 bucket permits anonymous modification or replacement of artifacts, so build integrity cannot be assured. It is tempting because public buckets simplify distribution to consumers, but that approach suits openly published release binaries, not integrity-protected pipeline artifacts.

Deleting build artifacts immediately after the deployment to production.

Why it fails: Deleting artifacts after deployment removes the evidence needed to verify what was actually shipped, so integrity cannot be audited or a compromised build traced. It is tempting as storage housekeeping, and would be reasonable for disposable intermediate build output that is never promoted or retained.

Uploading artifacts to a shared developer network drive.

Why it fails: A shared developer network drive offers no cryptographic verification or immutable versioning, so any developer with write access could alter a build after testing, defeating integrity. It is tempting because teams already use shared drives for convenience, and they would suit non-security-critical file exchange where provenance does not matter.

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.

Project Manager.

Why it fails: The Project Manager owns schedule, budget and scope, not security requirement elicitation; that task sits with the security architect or analyst who performs threat modelling and derives controls. It tempts because the PM coordinates early-phase activities and collates inputs, which is correct when the question concerns planning governance rather than identifying security requirements.

Software Tester.

Why it fails: Testers verify implemented behaviour against test cases, which occurs after requirements are defined, so they cannot own initial-phase security requirement identification. The temptation is that testers do find security defects, but that is validation, not elicitation; a security architect or business analyst performs this during requirements gathering.

Database Administrator.

Why it fails: The DBA administers schemas, backups and access to database instances, and enters after logical design; security requirements are elicited earlier by the security architect through threat modelling and abuse-case analysis. It tempts because DBAs do implement database-level controls, which is the right answer when the question concerns hardening a deployed data tier.

Automating the deployment pipeline to run security scans only after the production release.

Why it fails: Scanning only after production release places security outside the sprint, so findings cannot feed the Definition of Done before the increment is accepted. Pipeline scanning is correct when it runs on every commit, gating each build within the sprint.

Performing a full threat model for every user story.

Why it fails: A full threat model per story consumes sprint capacity and duplicates analysis already covered at the epic or feature level. Threat modelling suits architectural changes or new data flows, where a focused session identifies trust boundaries and mitigations before coding begins.

Conducting a penetration test at the end of every sprint.

Why it fails: A penetration test per sprint is periodic assurance, not a completion criterion, and its duration rarely fits a sprint, so it cannot gate the Definition of Done. Penetration testing is correct for periodic deep validation, whereas DoD needs automated checks on every increment.

To increase the speed of software compilation.

Why it fails: An SBOM lists components, versions and supply-chain relationships for transparency and vulnerability tracing; it has no effect on compilation performance. It is tempting because SBOM generation is often automated within build pipelines, but the artefact documents composition rather than optimising the build itself.

To automatically patch vulnerabilities in code.

Why it fails: An SBOM inventories components and dependencies, enabling identification of affected software when a vulnerability is disclosed; it does not patch code. It is tempting because SBOMs accelerate vulnerability response, but remediation remains the job of patch and dependency management tooling.

To replace the need for secure coding training.

Why it fails: An SBOM provides component transparency so known vulnerabilities and licence risks can be identified; it cannot substitute for secure coding training. It is tempting because both address software assurance, but training changes developer behaviour whereas an SBOM is a generated inventory artefact.

Total number of lines of code written.

Why it fails: Lines of code measures output volume, not security outcomes, so it cannot show whether the secure SDLC reduces vulnerabilities over successive releases. It tempts as a productivity proxy, and would be correct if the question asked about development throughput or effort estimation rather than security programme effectiveness.

Number of developers on the team.

Why it fails: Developer headcount is a resourcing measure and says nothing about whether security practices reduce vulnerabilities in delivered software. It tempts because larger teams appear to imply greater capability, and would be correct if the question asked about staffing capacity or team sizing rather than secure SDLC effectiveness.

Budget allocated to security tools.

Why it fails: Security tooling spend is an input cost, not evidence that the secure SDLC produces fewer defects or vulnerabilities across releases. It tempts because budget growth appears to signal commitment, and would be correct if the question asked how much the organisation invests in security rather than how effective the programme is.

Disable all rules except for critical-level vulnerabilities.

Why it fails: Restricting the tool to critical-level rules leaves injection, misconfiguration and other exploitable flaw classes undetected, so the pipeline passes vulnerable code. It is tempting because it cuts false positives and noise, and rule tuning would be correct when a mature ruleset produces excessive findings that developers already triage.

Run full scans on every single commit.

Why it fails: Full scans on every commit lengthen pipeline feedback to hours on large repositories, so developers wait rather than fix. It is tempting because full scans are correct for nightly or pre-release gates, where completeness matters and latency does not block individual commits.

Set the tool to break the build for every warning.

Why it fails: Failing the build on every warning blocks merges for informational and low-confidence findings, which is the friction the stem asks you to minimise. It is tempting because hard gating is right for a mature pipeline where the rule set has been tuned to near-zero false positives.

To perform all manual code reviews for the entire department.

Why it fails: Champions supplement peer review within their own team; centralising every manual code review on them creates a bottleneck and removes developer ownership. The model fits organisations wanting security-minded reviewers distributed across squads, not one person covering an entire department's review queue.

To handle all incident responses for the organization.

Why it fails: Incident response remains with the dedicated security operations function; champions lack the authority and tooling to coordinate organisation-wide incidents. The model is right when the goal is shifting security left into design and coding, not replacing the responders who handle active breaches.

To replace the need for professional security audits.

Why it fails: Security Champions embed security practise into delivery teams; they cannot substitute for independent assurance, which requires auditors outside the team. The model is correctly chosen when an organisation wants to scale security awareness across many squads without hiring dedicated security engineers for each one.

Verification phase.

Why it fails: Verification confirms that built artefacts meet specifications through testing and review of code, not design documentation; design review belongs earlier, in the design phase. It is tempting because verification is a formal review activity, and would be correct when validating that implemented components satisfy the design baseline.

Implementation phase.

Why it fails: Implementation produces code from the design, so reviewing design documentation then is too late to influence architecture; the design phase is where such review occurs. It is tempting because security testing and code review happen during implementation, and would be correct for reviewing source code rather than design documents.

Requirements phase.

Why it fails: Design documentation exists only once requirements are baselined, so a formal design review here has nothing to assess. Requirements-phase reviews examine requirement statements for completeness, testability and security criteria. This phase is tempting because security requirements gathering happens here, but reviewing design artefacts belongs to the design phase.

Using default security settings provided by the cloud provider.

Why it fails: Provider defaults are generic and often permissive, so they cannot satisfy the organisation's own baselines across build, deploy and runtime. It is tempting because defaults are pre-hardened and free, and they suit low-risk sandbox accounts, but the lifecycle demands codified, version-controlled configuration enforced by policy.

Relying on manual cloud console configuration.

Why it fails: Console configuration is undocumented, unrepeatable and drifts silently, so it cannot guarantee consistent secure settings across environments. It is tempting because the console is quick for one-off changes, and it suits exploratory or break-glass work, but the lifecycle requires configuration defined as code and validated in pipelines.

Performing monthly manual audits of cloud resources.

Why it fails: Monthly manual audits detect drift only after it has existed for weeks, leaving configuration unverified between checks. It is tempting because periodic review satisfies some compliance evidence requirements, and it suits small, static estates, but continuous automated scanning and policy enforcement are needed to catch drift as it occurs.

To calculate the financial loss of the incident.

Why it fails: Financial loss calculation is a function of cost or business-impact analysis, not a security Lessons Learned session, which examines control failures and process weaknesses to prevent recurrence. Quantifying loss is tempting because incident reporting often demands figures, but that satisfies finance and insurance needs rather than improving the software security programme.

To satisfy external auditors' compliance requirements.

Why it fails: Auditor satisfaction is an external compliance outcome, not the benefit of a Lessons Learned meeting, which produces internal corrective actions and shared knowledge. Compliance evidence is tempting because audits require documented reviews, yet a meeting held only to tick that box yields no genuine improvement to the secure development lifecycle.

To assign blame to the developer who wrote the code.

Why it fails: Blame assignment is not the purpose of a Lessons Learned review; the meeting exists to identify root causes and improve processes, and a punitive framing suppresses the honest reporting it depends on. It is tempting because accountability matters after incidents, but that belongs to HR or disciplinary procedures, not this retrospective.

Performing manual penetration tests on every commit.

Why it fails: Manual penetration testing on every commit cannot keep pace with continuous integration, blocking pipelines and destroying the velocity the stem requires. It tempts because penetration testing genuinely validates exploitable weaknesses, and it belongs in scheduled release cycles or pre-production gates rather than per-commit automation.

Waiting for the final release to review security documentation.

Why it fails: Deferring documentation review to final release reintroduces waterfall gating, so security issues surface after code is frozen and remediation stalls delivery. It tempts because formal review artefacts are genuinely required for compliance sign-off, but that review must run continuously alongside sprints, not at the end.

Conducting post-deployment vulnerability scanning.

Why it fails: Post-deployment scanning inspects running production workloads, which is detection after release rather than shifting security earlier into design and coding. It is tempting because continuous runtime scanning genuinely catches newly disclosed CVEs, and would be correct for ongoing operational vulnerability management of live systems.

Relying solely on external bug bounty programs.

Why it fails: Bug bounties operate after release, so they detect flaws once code is in production rather than during design or coding. They are tempting because crowd-sourced testing finds real exploitable issues at scale, and would suit an organisation seeking continuous external assurance for already-shipped software.

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.

Limiting access to all security documentation.

Why it fails: Restricting access to security documentation hides governance artefacts from auditors, developers and business stakeholders, preventing the alignment and accountability the stem requires. It is tempting as a confidentiality control, but documentation restriction belongs to data classification, not to demonstrating security alignment with business objectives.

Focusing exclusively on technical tool implementation.

Why it fails: Tool implementation addresses only technical controls, not the governance requirement of tying security objectives to business strategy through policy, risk appetite and executive oversight. It tempts because tooling does deliver control coverage, and would be correct when the question asks how to enforce a specific technical standard.

Increasing the number of security alerts for developers.

Why it fails: Raising alert volume increases developer workload without linking security outcomes to business objectives; governance needs defined roles, metrics and risk alignment. It tempts because alerting supports detection, and would be correct when the goal is improving monitoring coverage rather than strategic alignment.