Secure Coding and Application Security Questions

Covers the principles and practices for building and maintaining secure software throughout the secure software development lifecycle. Topics include secure coding patterns, common vulnerabilities and mitigations such as injection, cross site scripting, insecure deserialization, broken authentication and authorization, improper error handling, and insecure configuration. Includes threat modeling, secrets management, dependency and supply chain hygiene, vulnerability and patch management, and principles of least privilege and defense in depth. Covers code level controls such as input validation and output encoding, use of vetted libraries, avoiding dangerous custom cryptography, and guarding against side channel and timing attacks. Also covers security activities and tools including code review best practices, static application security testing, dynamic application security testing, interactive application security testing, dependency scanning, and how to integrate security testing and gates into continuous integration and continuous delivery pipelines to improve application security maturity.

HardTechnical

38 practiced

Design an automated vulnerability prioritization algorithm for SREs that combines CVSS, evidence of exploit, service criticality, SLO impact (error budget consumption), and whether the vulnerable component is present in production. Describe data inputs, scoring, and how the output integrates with ticketing and deployment workflows.

Sample Answer

Requirements & constraints:- Prioritize vulnerabilities for SRE action using CVSS, exploit evidence, service criticality, SLO impact (error budget risk), and production presence.- Low latency, auditable scores, integration with ticketing (Jira) and deployment pipelines (CI/CD), configurable thresholds per team.

High-level design:1. Data inputs- Vulnerability feed: vuln ID, CVSS v3 vector & score, published date (from scanners, NVD, vendor advisories).- Threat intelligence: exploit observed (proof-of-concept, active exploit, exploit in wild) with confidence score.- Inventory: asset → service mapping, environment (prod/staging), component versions (from CMDB / service registry / runtime agents).- SLO metadata: per-service SLOs, current error budget consumption and burn rate (from SLO system).- Business criticality: service tier (P0–P3), uptime/latency sensitivity, cost of failure.- Historical fixes: time-to-patch baselines per team.

2. Scoring model (explainable, weighted)- Normalize each input to 0–1: - CVSS_norm = CVSS_score / 10 - Exploit_norm = {none:0, PoC:0.5, active:1} × confidence - Prod_presence = 1 if component found in prod else 0.2 if only staging - SLO_risk = min(1, projected_error_budget_loss / remaining_error_budget) - Criticality_norm = map P0→1.0, P1→0.75, P2→0.4, P3→0.1- Composite priority score: Priority = w1*CVSS_norm + w2*Exploit_norm + w3*Prod_presence + w4*SLO_risk + w5*Criticality_norm Default weights: w1=0.2, w2=0.3, w3=0.15, w4=0.25, w5=0.1 (tuneable per org)- Boosters/penalties: age since disclosure, presence in public exploit repos (+), mitigations detected (-).

3. Outputs & thresholds- Priority bucket: Critical (score>0.85), High (0.65–0.85), Medium (0.4–0.65), Low (<0.4).- Recommended SLA: e.g., Critical → patch or mitigated in 24h; High → 7 days.- Actionable artifacts: explanation of score, evidence links, affected hosts, suggested remediation (upgrade, config, firewall rule), rollback plan.

4. Integration & automation- Ticketing: Auto-create Jira tickets with priority, labels, affected services, owner assignment via ownership map; attach score breakdown and remediation playbook.- CI/CD: Gate deployments for components with Critical/High unmitigated vulns via pre-deploy checks; allow temporary exceptions with risk-acknowledgement workflow tied to ticket.- Runbooks: For Critical, trigger pager/alert to on-call with remediation steps and automated mitigation playbooks (e.g., WAF rules, interface-level blocking).- Orchestration: For containerized fleets, automated canary patch rollout pipelines that patch low-risk groups first and monitor SLOs.

5. Feedback & governance- Closed-loop: ticket resolution updates vulnerability state; rescans re-evaluate score; ML model retrains weights using outcomes (time-to-fix vs incidents).- Metrics: time-to-detect, time-to-create-ticket, time-to-remediate by priority, false positives, SLO impact post-remediation.

Example flow:- Scanner reports CVE-2025-1234 with CVSS 9.1 on library X.- TI shows active exploit → Exploit_norm=1.0. Inventory shows presence in prod for two P0 services → Prod_presence=1, Criticality_norm=1, SLO_risk=0.6.- Priority computes to 0.92 → Critical. System auto-creates ticket, pages on-call, applies emergency WAF rule, and triggers a canary patch pipeline.

Trade-offs:- Simplicity vs accuracy: weighting must be explainable to gain trust.- False positives: prefer conservative prod presence detection and confidence thresholds for exploit intel.

This design yields an auditable, automated prioritization loop that ties vulnerability data to operational impact and SRE workflows while remaining configurable and measurable.

EasyTechnical

68 practiced

Define a software supply chain attack and describe immediate and ongoing controls an SRE team should implement to reduce risk from third-party dependencies. Include SBOM generation, dependency pinning, artifact signing, private registries, and build isolation in your answer.

Sample Answer

A software supply chain attack is when an attacker compromises a component, tool, or process used to build, package, or deliver software (e.g., a malicious npm package, compromised CI runner, or tampered container image) so that downstream systems run attacker-controlled code. For an SRE team, reduce risk with immediate and ongoing controls:

Immediate controls- Inventory & SBOM: Generate SBOMs for services and images (CycloneDX/SPDX) to know exactly which packages and versions are in use; integrate SBOM creation into builds.- Dependency pinning: Enforce pinned versions (lockfiles) in CI to avoid pulling floating versions; fail builds when lockfile changes are unreviewed.- Private registries: Configure private/proxy registries (Artifact Registry, Nexus, Artifactory) to cache vetted packages and block unapproved sources.- Artifact signing: Require signed build artifacts and container images (sigstore/cosign); verify signatures in deployment pipelines.- Build isolation: Run builds in ephemeral, minimal CI runners or dedicated build clusters with least privilege and network egress restrictions; don't build on developer machines for production artifacts.

Ongoing controls- Automated scanning: Continuously scan SBOMs and artifacts for known vulnerabilities (OSV, Snyk, Clair) and high-risk licenses.- Reproducible builds & provenance: Capture build provenance (who/what/when) and use reproducible builds to detect tampering.- Policy enforcement: Use policy-as-code (OPA/Gatekeeper) to enforce pinned dependencies, signature verification, and registry sources before deploy.- Patch & rotation cadence: Regularly update pinned dependencies via automated PRs, test, and deploy; rotate credentials for registries and signing keys.- Monitoring & alerting: Monitor for unusual dependency changes, failed signature verifications, or unexpected outbound CI traffic; alert and run incident playbooks.- Incident readiness: Maintain rollback images, immutable artifact storage, and playbooks that use SBOMs to identify affected services.

These controls combine detection, prevention, and rapid response—practical for SREs who must keep systems reliable while minimizing third-party risk.

EasyTechnical

40 practiced

Discuss how static-typed versus dynamic-typed languages impact injection vulnerabilities. Regardless of language, propose a set of runtime defenses and operational controls an SRE team can apply to reduce injection risk across heterogeneous services.

Sample Answer

Static typing vs dynamic typing and injection risk:- Static-typed languages (e.g., Java, Go) catch many type errors at compile time and encourage explicit schemas/typed APIs, which reduces some classes of developer mistakes that can lead to injections (e.g., accidentally concatenating heterogeneous types). However, static typing does not eliminate injection vulnerabilities because injections arise from unsafe string construction, not type system alone.- Dynamic-typed languages (e.g., Python, JavaScript) make it easier to build strings on the fly and may encourage more ad-hoc concatenation; this can increase developer exposure to mistakes. Still, safe libraries and disciplined patterns prevent injections equally well in dynamic languages.

Runtime defenses (language-agnostic, apply across services):- Parameterized queries / prepared statements for databases (never string concatenation).- Use safe APIs/escaping libraries for command execution (avoid shell interpolation; prefer execv-style APIs).- Input validation and canonicalization at service boundaries (whitelisting preferred).- Web application firewall (WAF) with tuned rules to block common SQL/command injection patterns.- Runtime application self-protection (RASP) to detect and block suspicious query patterns in-process.- Output encoding for contexts (HTML, JSON, shell) before rendering or executing.

Operational controls for SREs:- Enforce dependency policies: block known-vulnerable libraries and ensure vetted escaping/DB client libs via CI/CD.- Static and dynamic scanning in CI: SAST for unsafe string usage patterns, DAST/fuzzing in staging to find injection vectors.- Service-level input contracts: OpenAPI/Protobuf schemas and gateway validation to reject malformed inputs early.- Least-privilege credentials: DB and OS accounts limited to required operations; use separate readonly accounts where possible.- Logging, monitoring, and alerting: detect spikes in rejected queries, anomalous error patterns, or unusual query shapes; integrate into incident playbooks.- Canary/testing: deploy WAF/RASP and tuning in canary to reduce false positives.- Runbooks and developer training: require secure coding practices, code reviews focused on injection risks.

Why this helps: these defenses layer protection — prevent unsafe code patterns (CI and libs), block exploitation at runtime (WAF/RASP/gateway), and reduce blast radius (least privilege, monitoring). Together they reduce injection risk across heterogeneous stacks irrespective of typing discipline.

HardSystem Design

45 practiced

Design defense-in-depth for an internal administrative portal used by SREs and engineers. Cover authentication (MFA), network segmentation, privileged access workstations (PAW), just-in-time access, audit logging, session management, and break-glass emergency access. Explain how each control reduces risk.

Sample Answer

Requirements & goals:- Protect internal admin portal used by SREs/engineers: confidentiality, integrity, availability, and non-repudiation.- Minimize blast radius, detect misuse, enable rapid recovery and emergency access.

High-level architecture:- Identity Provider (IdP) + Conditional Access → Admin Portal front-end → Management plane (jump hosts / PAWs) → Backend services (APIs, infra).- Central SIEM + immutable audit store; Privileged Access Management (PAM) for JIT and session recording.

Controls and how they reduce risk:

1) Authentication (MFA, IdP + conditional access)- Use enterprise IdP (OIDC/SAML) with phishing-resistant MFA (FIDO2/WebAuthn + hardware tokens) and fallback TOTP for non-supported devices.- Enforce device posture (MDM), geo/IP allowlist, and risk-based conditional access.- Risk reduction: prevents credential theft/replay, blocks compromised credentials by requiring second factor and device health.

2) Network segmentation- Place admin portal and management interfaces in isolated management VPC/subnet accessible only from corporate network or VPN with enforced ACLs.- Use bastion/jump hosts in a separate management tier; block direct access to control plane from general networks.- Risk reduction: limits lateral movement and exposure of admin interfaces to compromised hosts/networks.

3) Privileged Access Workstations (PAW)- Require PAWs or hardened jump hosts for admin tasks: locked-down OS, no email browsers, disk encryption, strict patching, full-disk MFA on boot.- All admin work must originate from PAW (enforced via conditional access / device certificates).- Risk reduction: reduces malware/phishing attack surface and prevents credential exfiltration from general-purpose endpoints.

4) Just-In-Time (JIT) access via PAM- Integrate PAM to grant time-bound elevated roles after approval (ticket or automated policy), with auto-expiry and MFA re-affirmation.- Use role-based least privilege (RBAC) and temporary session tokens (short TTL).- Risk reduction: minimizes standing privileges, reduces window for misuse, enforces approval/audit trail.

5) Audit logging / immutable evidence- Centralize logs (auth, API calls, PAM events, OS-level) to SIEM and append-only immutable storage (WORM/S3 with object lock).- Correlate with IDS/EDR and retain per compliance policy; alert on anomalies (privileged access outside business hours, impossible travel).- Risk reduction: forensic capability, non-repudiable trails, quicker detection of abuse and root-cause analysis.

6) Session management & recording- Enforce session timeouts, single active session per user per environment, IP/device binding for sessions.- For privileged sessions, enable full session recording (shell/API), integrity checks, and tamper-evident storage.- Risk reduction: deters misuse (users know they're recorded), provides forensic playback and attribution, limits session hijack life.

7) Break-glass emergency access- Implement documented break-glass with separate emergency accounts stored in an armored vault (offline or HSM-backed), multi-person approval (2-person) or out-of-band approval, time-limited tokens, and mandatory post-use review.- Automatically rotate emergency credentials after use and require forensic logging and retroactive approval.- Risk reduction: guarantees availability for critical recovery while ensuring accountability and reducing potential for abuse.

Operational considerations & trade-offs:- Balance friction vs. security: use risk-based policies to reduce unnecessary MFA prompts.- Test incident scenarios and drill break-glass flows to ensure timeliness.- Monitor costs/latency from session recording and long-term log retention; tier retention and archive older data.- Regular audits, access recertification, and automated orphaned-privilege removal.

Summary:Combine strong, phishing-resistant MFA, segmented networks, PAWs, JIT privileged access, immutable logging, strict session controls, and a controlled break-glass process. Each layer reduces attack surface, limits dwell time and lateral movement, and increases detection and accountability—providing defense-in-depth appropriate for SRE/admin workflows.

MediumTechnical

35 practiced

For a Java web application in production, propose a runtime application self-protection (RASP) strategy to detect and prevent SQL injection and insecure deserialization with minimal performance impact. Explain instrumentation points, sampling, response actions, and trade-offs.

Sample Answer

Approach summary:Use a lightweight Java agent that instruments hot paths (HTTP handlers, JDBC entry points, and Java deserialization APIs) to detect/prevent SQLi and insecure deserialization with minimal latency by combining targeted bytecode instrumentation, sampling, async telemetry, and adaptive blocking.

Instrumentation points:- HTTP layer (Servlet filter / framework entry points) — mark request parameters as tainted (metadata only).- JDBC entry points: - Intercept java.sql.Statement.execute*/executeQuery and java.sql.PreparedStatement constructors via a Java agent (Byte Buddy / ASM). - For PreparedStatement: verify parameters are bound (avoid concatenation). - For Statement: capture SQL string before execution.- Deserialization: - Instrument java.io.ObjectInputStream.readObject and javax.* or framework-specific deserializers to check class names and apply JEP-290 serialization filters (java.io.ObjectInputFilter). - Hook resolveClass/resolveObject to enforce allowlists and detect gadget patterns.- Runtime: use JVMTI/Byte Buddy to inject checks without recompiling app.

Detection logic & sampling:- SQLi: - Fast heuristic checks on SQL strings and parameter values: presence of SQL meta-characters in unbound inputs, tautologies, comment tokens. - If query built via concatenation of tainted inputs -> high risk. - Use tiered sampling: inspect 1% of requests in depth, 100% for requests that hit heuristics threshold; escalate sampling for an endpoint after N suspicious events.- Deserialization: - Apply allowlist/denylist filters always for classes; heavy gadget-pattern detection (taint propagation, reflection usage) sampled at low rate (1-5%) and triggered fully on suspicious input.- Always keep synchronous checks cheap (string pattern checks, class name allowlist). Heavy analysis (taint propagation, bytecode pattern matching) async or sampled.

Response actions:- Low-confidence detection: log full context (sanitized), emit alert to SIEM/monitoring, increment anomaly counter.- Medium-confidence: block request with 403 and a generic error page; return minimal info to client. Record forensic trace asynchronously.- High-confidence (e.g., concatenation of tainted input into Statement or disallowed deserialization class): immediate block and drop execution, optionally close session/token and trigger automated incident runbook (rate-limited).- Adaptive controls: if a service sees rapid false positives, autoswitch to “alert-only” for that endpoint and notify owner.

Performance / reliability safeguards:- Make agent opt-in per service and default to read-only monitoring.- All heavy work is offloaded to background worker threads; synchronous path limited to cheap checks and counters.- Use bounded async queues and backpressure — if queues fill, degrade to sampling-only to preserve throughput.- Metrics: latency P50/P99, blocked requests, false-positive rate, CPU overhead. Set SLO that agent must not add >2% CPU or >5ms P99 latency; tune sampling accordingly.

Trade-offs:- False positives vs safety: blocking reduces risk but can impact availability; use staged blocking with escalation and whitelisting.- Coverage vs performance: full taint-tracking detects more but is expensive; sampling + heuristics gives practical balance.- Maintenance: bytecode instrumentation and serialization filters require careful testing across JVM versions and frameworks.- Compatibility: some frameworks/third-party libs may break if classes are instrumented; provide opt-out lists.- Operational complexity: need alerting, incident playbooks, and periodic tuning of heuristics and allowlists.

Example quick wins:- Deploy agent in monitoring mode for 2 weeks, analyze noisy endpoints, add allowlists, then enable blocking for high-confidence rules.- Enforce PreparedStatement usage as a dev-time rule and surface violations via runtime telemetry to dev teams.

This strategy minimizes runtime impact by keeping synchronous checks lightweight, using sampling and async analysis, and applying blocking only when confidence is high or patterns repeat.

Unlock Full Question Bank

Get access to hundreds of Secure Coding and Application Security interview questions and detailed answers.

Join thousands of developers preparing for their dream job.