Secure Coding and Code Review Questions

Principles, techniques, tooling, and processes that prevent security vulnerabilities through developer practices and structured review. Topics include input validation and sanitization, output encoding, bounds checking and memory safety, safe application programming interface usage, defensive programming, secure authentication and authorization patterns, secure error handling and logging without leaking secrets, secrets management and avoiding hard coded credentials, correct use of cryptographic primitives and libraries, secure deserialization, dependency and supply chain management, and threat modeling at the code level. Also covers code review practices focused on security such as checklists and threat oriented heuristics, automation and integration with static application security testing and dynamic analysis, pull request policies, triage and remediation workflows, balancing review thoroughness with development velocity, developer security training and awareness programs, metrics for review effectiveness, and strategies to embed security into the software development lifecycle.

EasyTechnical

54 practiced

Explain secure error handling and logging practices in application code. Describe what information should never be logged (plaintext secrets, full raw tokens, raw PII), how to sanitize or redact sensitive fields, how to format logs for secure consumption, and how to design user-facing error messages that are actionable for support while not leaking sensitive implementation details to an attacker.

HardTechnical

55 practiced

Propose a method to measure the ROI of security training and secure code review processes. Define baseline measurements, controlled experiments (control and treatment groups), metrics to track (pre/post defect rates, severity-weighted defects, time-to-fix, developer satisfaction), a statistical approach for attribution, and how to account for confounding variables like changing codebase size or hiring.

Sample Answer

**Approach overview**I would treat ROI measurement as an experiment + operational metrics pipeline: establish baselines, run controlled interventions, track security and business metrics, and use statistical models to attribute effect while controlling for confounders.

**Baseline**- Collect 6–12 months pre-intervention data: vulnerability counts by CWE/severity, defects per KLOC, false positives, time-to-fix, security-related incidents, developer satisfaction (survey), and developer throughput.

**Controlled experiment design**- Randomize at team or repo level (cluster randomization) to avoid contamination.- Control group: business-as-usual reviews/training.- Treatment groups: (A) secure code reviews added, (B) training program, (C) both.- Run for a quarter–two quarters; ensure similar codebase mix per cluster.

**Metrics to track**- Pre/post defect rates (defects per KLOC and per release)- Severity-weighted defects (assign weights e.g., Critical=10, High=5, Medium=2)- Time-to-fix for security defects- Escape rate: defects found in production vs. pre-prod- Developer satisfaction and confidence (Likert surveys)- Cost inputs: training cost, reviewer hours, remediation cost- Business ROI = (reduction in expected incident cost + reduced remediation effort) − program cost

**Statistical attribution**- Use difference-in-differences (DiD) on cluster-level panels to estimate causal effect: - Fit mixed-effects regression: outcome ~ treatment * post + covariates + (1|cluster)- For count outcomes use negative binomial/Poisson GLMM; for time-to-fix use survival models.- Report confidence intervals, p-values, and effect sizes; run power analysis up front.

**Handling confounders**- Include covariates: repo size, churn, hiring rate, tech stack, release frequency.- Normalize metrics per KLOC or per developer-month.- If hiring or major changes occur, add time-varying covariates or exclude windows.- Sensitivity analysis: placebo tests, permutation tests, and A/B subgroups.

**Operationalize**- Automate data collection via CI/CD, SCA/SCM integrations, ticketing exports, and periodic surveys.- Present dashboard: baseline vs. treatment, cost-benefit, and recommended next steps (scale, modify, or sunset).

MediumTechnical

46 practiced

Create unit test scenarios for a function that encrypts user data using AES-GCM with a provided 256-bit key and returns a base64-encoded ciphertext. Provide at least five test scenarios with rationale: correct decryption, tampering detection (modified ciphertext), nonce reuse detection/handling, invalid key handling, and boundary inputs (empty plaintext). Use the language of your choice and describe what each test asserts.

Sample Answer

**Approach (brief)** As a cybersecurity engineer I'd write unit tests that exercise correctness, integrity, nonce/key handling, and edge cases. Below are five concrete test scenarios (using Python + pytest and cryptography.io style pseudocode snippets) with rationale and explicit assertions.

**1) Correct decryption (happy path)** Rationale: Verify encryption is reversible with same key/nonce. Test: encrypt(plaintext, key) -> b64; decode & decrypt -> plaintext. Assert: decrypted == original; ciphertext != plaintext (ensures actual encryption).

python

ct_b64 = encrypt(b"secret", key256)
ct = base64.b64decode(ct_b64)
pt = decrypt(ct, key256)
assert pt == b"secret"
assert ct != b"secret"

**2) Tampering detection (modified ciphertext)** Rationale: AES-GCM provides AEAD; tampering must fail authentication. Test: flip a byte in ciphertext or tag, then decrypt -> exception. Assert: decryption raises InvalidTag / authentication error.

python

ct = bytearray(base64.b64decode(encrypt(b"m", key)))
ct[10] ^= 0x01
with pytest.raises(InvalidTag): decrypt(bytes(ct), key)

**3) Nonce reuse detection/handling** Rationale: Reusing nonce with same key breaks confidentiality. Ensure implementation generates unique nonces; detect reuse in tests. Test A: call encrypt twice and assert nonces differ; Test B: simulate reuse and observe weakened security (e.g., XOR of plaintexts equals XOR of keystreams) — at minimum assert nonces are unique per call.

python

ct1, meta1 = encrypt_with_meta(b"a", key)
ct2, meta2 = encrypt_with_meta(b"b", key)
assert meta1.nonce != meta2.nonce

**4) Invalid key handling** Rationale: Wrong key must fail to decrypt and should not leak plaintext. Test: decrypt valid ciphertext with different 256-bit key -> InvalidTag or gibberish. Assert: decryption raises InvalidTag or result != original.

python

with pytest.raises(InvalidTag): decrypt(base64.b64decode(ct_b64), wrong_key)

**5) Boundary inputs (empty plaintext, large plaintext)** Rationale: Ensure empty plaintext encrypts/decrypts and that large inputs stream correctly. Test: encrypt(b"") -> decrypt -> b""; encrypt large payload (e.g., 10MB) roundtrips. Assert: decrypted == original; operation completes within expected memory/time limits.

Additional assertions: tag length (e.g., 16 bytes), ciphertext contains IV/nonce of expected size, base64 is valid UTF-8. Include mocks or fuzzing for robustness.

EasyTechnical

44 practiced

What are core code-level practices for secure dependency management? Discuss pinning versions, generating and using SBOMs, verifying package signatures/provenance, scanning for known vulnerabilities, and applying policies for transitive dependencies. Give an example policy you would enforce in pull requests when a dependency is updated.

HardSystem Design

57 practiced

Design an enterprise-level secure code review program that can scale to 300+ engineers and 200 microservices. Include proposed processes, tooling (SAST, DAST, linters, code-hosting integrations), roles (security champions, triage owners, reviewers), training cadence, enforcement versus advisory controls, CI/CD integration, pilot plans, and KPIs to measure success. Explain trade-offs in automation vs human review and how to get executive buy-in.

Sample Answer

**Overview & goals**Design a scalable Secure Code Review (SCR) program to reduce exploitable defects, shift left security, and enable 300+ engineers across 200 microservices with minimal release friction.

**Requirements & constraints**- Scale, low dev friction, measurable reduction in high-severity findings, incremental rollout, CI/CD-first.

**High-level architecture**- Developer IDE/PR feedback loop -> Automated SAST/linters in CI -> DAST in pre-prod -> Human triage & reviewer workflow integrated in code-hosting (GitHub/GitLab) -> Issue tracking + metrics dashboard.

**Tooling**- SAST: Commercial (e.g., Semgrep for rules + SonarQube) tuned per stack.- Linters: ESLint, bandit, gosec with org-wide rule-sets.- DAST: OWASP ZAP or commercial for authenticated scans in staging.- Code-hosting integrations: GitHub checks, protected branches, required status checks.- Triage / tracking: Jira + security pipeline (Slack/MS Teams alerts).- Secrets scanning: pre-commit hooks + server-side scanners.

**Roles & responsibilities**- Security Engineers: program ownership, rule tuning, triage.- Security Champions: one per team — first-line reviewer and trainer.- Triage Owners: rotate among senior security engineers for SLA.- Reviewers: peer dev reviewers + security champion for high-risk PRs.- Engineering managers: enforcement policy & budget.

**Processes**- PR policy: block merge if high-severity SAST/secret findings; advisory for low-medium.- Triage flow: automated findings -> dedupe -> assign to triage owner -> classify (false positive / fix / rule tuning).- Human review trigger: new critical findings, auth/data-flow changes, infra-as-code changes.

**CI/CD integration**- Fast feedback: lightweight linters run locally/CI on every PR.- Gate checks: SAST incremental analysis in PR; full SAST and DAST in merge pipeline.- Auto-fix where safe (linters), otherwise require remediation tickets.

**Training cadence**- Onboarding: 2-hour secure coding + tool walkthrough.- Ongoing: monthly 45-min micro-training + quarterly hands-on SRE red-team labs.- Security champions: quarterly advanced workshops.

**Pilot plan**- Phase 0 (4 weeks): select 6 teams (varied stacks), baseline metrics.- Phase 1 (8 weeks): enable linters + PR checks + champions.- Phase 2 (12 weeks): add SAST+DAST; refine rules.- Rollout with feedback loops and SLA targets.

**KPIs**- Time-to-fix critical findings- Number of critical/high findings per release- False positive rate (triage overhead)- % PRs with security checks passing- Training completion & champion coverage- Mean time to triage

**Automation vs Human review trade-offs**- Automation: scales, immediate, enforces basics, but high FP rate and misses logic/authorization flaws.- Human review: catches business-logic issues and contextual risks but slower and costly.- Hybrid: automate routine checks and escalate high-risk and context-dependent findings to humans; tune rules to lower FP.

**Enforcement vs Advisory**- Enforcement for secrets, critical SAST, policy checks via CI gates.- Advisory for medium/low findings with warnings and remediation tickets; pair with incentives and backlog prioritization.

**Executive buy-in**- Present baseline risk + cost model: exploit cost vs remediation cost.- Pilot results: show KPIs improvement and reduced time-to-fix.- Compliance & audit benefits; map to business objectives (availability, reputation).- Ask for small investment (tools + 0.5 FTE sec eng + training budget) with staged ROI checkpoints.

**Risks & mitigations**- Alert fatigue: continuous rule tuning and champion feedback loop.- Slow pipelines: incremental analysis and caching.- Adoption: leadership KPIs, manager incentives, and make fixes easy (templates, autofix).

This design balances automation and human judgment, provides clear roles and metrics, and stages rollout to prove value and secure executive support.

Unlock Full Question Bank

Get access to hundreds of Secure Coding and Code Review interview questions and detailed answers.

Join thousands of developers preparing for their dream job.