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

46 practiced

You must threat-model a new serverless payment-processing function: it retrieves secrets from a store, calls external payment gateways, and writes results to a DB. Produce a concise threat-model output: (A) a textual data-flow summary, (B) the top five threats ranked by risk, and (C) prioritized mitigations that fit a compliance-minded but agile team.

Sample Answer

**(A) Data-flow summary (textual DFD)**

- Client → API Gateway (HTTPS, auth token) → Serverless function (retrieves secrets from Secrets Store, validates request) - Function → External Payment Gateway(s) (mutual TLS / API keys) → Payment responses → Function - Function → Database (writes transaction records, status, non-sensitive metadata) - Monitoring/Logging sinks capture metrics and traces (redacted PII) - IAM roles govern function access to Secrets Store and DB

**(B) Top 5 threats (ranked by risk)**

1. Compromised secrets (secrets store credentials/API keys exfiltrated) — High 2. Supply-chain or function code compromise (malicious dependency/backdoor) — High 3. Man-in-the-middle or credential replay to payment gateway (network/insufficient TLS/misconfigured mTLS) — High-Medium 4. Excessive logging leakage of PII/payment data (logs, traces, third-party monitoring) — Medium 5. Privilege escalation via over-permissive IAM role allowing lateral DB access or secret rotation abuse — Medium

**(C) Prioritized mitigations (compliance-minded, agile)**

1. Secrets & keys: enforce KMS-backed secrets, short-lived credentials, automatic rotation, and least-privilege access via granular IAM roles (must-have, implement first sprint). 2. Code integrity: enable signed build artifacts, SCA for dependencies, CI gate with SBOM and automated tests (high priority, integrate into CI pipeline). 3. Network security: require mTLS to payment gateways, enforce TLS 1.2+, restrict egress with allowlists and VPC endpoints (deploy alongside secrets rotation). 4. Data protection & logging: redact PII at source, use structured logs with tokenization, store sensitive fields encrypted-at-rest with separate KMS keys and access auditing (compliance requirement). 5. Monitoring & detection: enable runtime anomaly detection, alerting for abnormal secret usage, and automated revocation playbooks; periodic pen-tests and drift checks (ongoing cadence).

Implementation notes: prioritize controls that are automatable (CI/CD gates, rotation, egress policies) to keep agility while meeting compliance auditability (logging of key rotations, artifact signatures, and access reviews).

HardTechnical

58 practiced

Design an approach to integrate Interactive Application Security Testing (IAST) into integration and system tests for a complex monolith. Cover agent instrumentation, performance impact, selective test coverage to reduce noise, how findings will be triaged and surfaced to developers, and strategies to reduce false positives.

Sample Answer

**Overview / Goal**Design IAST so integration/system tests exercise real app behavior with minimal overhead, high signal-to-noise, and actionable developer feedback.

**Agent instrumentation**- Use a lightweight runtime agent (bytecode/in-process) that hooks sink/source APIs and framework middleware (DB clients, templating, auth libraries). - Enable on-demand agent activation via test profile or env var to restrict to CI test stages. - Provide agent config as code (YAML) stored in repo; CI injects via container/VM image.

**Performance impact**- Start with sampling + staged enablement: run full test suite with agent sampling 1 in N tests, run targeted suites with full tracing. - Profile agent overhead (benchmark) and disable expensive deep-taint modes by default. - Use asynchronous batched reporting to avoid blocking tests.

**Selective coverage to reduce noise**- Map tests -> features using tags; enable IAST only for integration/system tests tagged with security or high-risk features (auth, file handling, input parsing). - Use baseline allowlist of known safe sinks (third-party libs) and test-specific whitelists.

**Triage & developer feedback**- Integrate results to CI: fail build on high-severity findings; open structured tickets on low/medium with stack trace, request/response sample, and test that triggered it. - Push findings into dev tools: annotated PR comments, Slack alerts for owners, and grouping dashboard (per-app, per-endpoint).

**Reducing false positives**- Correlate dynamic evidence: require exploitability conditions (taint flow + reachable sink + runtime context) before surfacing. - Use replayable minimal repro captured during the test to let developers confirm. - Provide tooling to mark findings as false positive or accepted with metadata; feed back to agent allowlists.

**Operational practices**- Run nightly full-scan with deeper taint to find rare flows; keep CI runs focused and fast. - Maintain metrics: signal/noise ratio, time-to-fix, flake rate — iterate agent config by these metrics.

HardTechnical

35 practiced

You have a growing backlog of high-volume SAST and DAST findings across many teams but limited security engineering bandwidth. Design a remediation program including triage/prioritization, automated suppression for accepted and documented risks, developer incentives (training/bug-bounty/credits), a security champions model, and metrics to track mean-time-to-remediate and program health.

Sample Answer

**Situation & goal (one line)** Design a scalable remediation program to reduce SAST/DAST backlog with limited security engineering bandwidth while keeping risk controlled.

**Triage & Prioritization**- Auto-enrich findings with asset criticality, exploitability (CVE/Exploit DB), business impact, and code owner via CI/CD metadata.- Prioritize by risk score = CVSS*asset_criticality*exploitability_weight; surface Top-20% weekly SLA (e.g., Critical: 7 days, High: 30 days, Medium: 90 days).- Use automated grouping/deduplication to collapse noise (fingerprinting identical findings).

**Automated Suppression & Accepted Risks**- Implement an evidence-backed exception workflow in the VM tool (e.g., DefectDojo, Jira + webhook). Exceptions require: business justification, compensating control, expiry date, approver.- Auto-suppress low-confidence or false-positive patterns with periodic re-scan triggers and audit logging.

**Developer Incentives**- Training: role-based secure coding modules tied to onboarding and quarterly micro-training with completion badges.- Credits: issue “security credits” redeemable as time allocation or recognition for fixing backlog items.- Bug-bounty/spot rewards: internal bounty for first-to-fix High/Critical within SLA with monetary/recognition rewards.

**Security Champions Model**- Nominate champions per team; formalize responsibilities, quarterly training, monthly office hours.- Champions get KPIs (fix rate, triage throughput) and a lightweight playbook (triage checklist, common fixes, escalation path).- Central security engineers focus on escalations, complex reviews, and tool tuning.

**Automation & Tooling**- Integrate SAST/DAST into CI pipelines, auto-create tickets with remediation hints and code snippets, link to PR templates.- Use static analyzers’ suppressions only when paired with exception tickets; leverage SCA for dependency issues.

**Metrics & Health**- Mean-Time-To-Remediate (MTTR) by severity (start = ticket open; end = verified fix).- Backlog size & trend (by severity and age buckets).- Fix rate per team and per champion.- False positive rate and exception count/age.- SLA compliance percentage and time-to-triage.- Weekly dashboard + monthly review with RAG thresholds.

**Example KPI targets**- Critical MTTR ≤ 7 days; High ≤ 30 days; SLA compliance ≥ 90%.- Reduce backlog >90 days by 50% in 90 days.

Why this works: automation reduces noise and ticket churn, champions scale domain knowledge, incentives drive behavior change, and strict metrics ensure accountability and continuous improvement.

MediumTechnical

40 practiced

Provide pseudocode or a short Java example showing safe deserialization practices with Jackson or core Java: include whitelisting allowed types, limiting input size, and avoiding polymorphic type resolution. Explain why each step mitigates deserialization attacks.

Sample Answer

**Approach (brief)** Safe deserialization requires: whitelist allowed types, limit input size, and avoid polymorphic type resolution. Below are short Java examples (Jackson and core Java) plus why each step reduces risk.

**Jackson (preferred)**

java

// Jackson 2.10+ with PolymorphicTypeValidator whitelist
PolymorphicTypeValidator ptv = BasicPolymorphicTypeValidator.builder()
  .allowIfSubType("com.mycompany.safe.") // whitelist package/class prefix
  .build();

ObjectMapper mapper = new ObjectMapper();
mapper.activateDefaultTyping(ptv, ObjectMapper.DefaultTyping.NON_FINAL); // controlled typing

// limit size: wrap InputStream
try (InputStream in = new BoundedInputStream(rawStream, 10_240)) { // 10 KB max
  MySafeClass obj = mapper.readValue(in, MySafeClass.class);
}

**Core Java (ObjectInputStream)**

java

// override resolveClass to enforce whitelist
class SafeObjectInputStream extends ObjectInputStream {
  SafeObjectInputStream(InputStream in) throws IOException { super(in); }
  @Override protected Class<?> resolveClass(ObjectStreamClass desc) throws IOException, ClassNotFoundException {
    String name = desc.getName();
    if (!name.startsWith("com.mycompany.safe.")) throw new InvalidClassException("Unauthorized class: " + name);
    return super.resolveClass(desc);
  }
}

// use bounded stream
try (InputStream in = new BoundedInputStream(rawStream, 10_240);
     ObjectInputStream ois = new SafeObjectInputStream(in)) {
  Object o = ois.readObject();
}

Why each step mitigates attacks- Whitelisting allowed types: prevents attackers from instantiating gadget classes (shells, RCE vectors) by only permitting known-safe classes/packages.- Limiting input size: avoids resource exhaustion (large payloads causing OOM or prolonged parsing) and reduces attack surface for complex chained payloads.- Avoiding polymorphic type resolution / controlling typing: blocks attackers from specifying arbitrary implementation classes via metadata (e.g., @class) which is a common vector for insecure-deserialization exploits.

Additional best practices- Prefer explicit typed deserialization (mapper.readValue(in, MySafeClass.class)) rather than any polymorphic mechanisms.- Validate object fields after deserialization.- Keep libraries up-to-date and run static/dynamic checks.

EasyTechnical

37 practiced

Explain the principle of least privilege and describe three concrete ways you would apply it for a new REST API and its deployment environment (examples: IAM roles for services, database credentials, container runtime capabilities). For each way, include how you would validate the control and a monitoring signal that would indicate it is misconfigured.

Sample Answer

**Principle (brief)** Least privilege means granting each identity, process, or component only the minimum permissions necessary to perform its function — reducing attack surface and blast radius.

**1) IAM roles for services** - Apply: Create narrow, task-specific roles (e.g., read-only config store role, token-issuing role) and use short-lived credentials (STS). Enforce role separation per microservice. - Validate: Review IAM policies with automated policy linting (check for wildcard actions/resources) and run automated conformance tests that exercise only allowed APIs. - Monitoring signal: Alerts on policy-denying logs are normal; a spike of “AccessDenied” followed by fallback to broader service account use or creation of temp policies indicates misconfiguration.

**2) Database credentials & least-privileged DB users** - Apply: Create DB users scoped to schema/queries (e.g., orders_service user with SELECT/INSERT on orders table only). Use vault-backed dynamic credentials rotated frequently. - Validate: Run integration tests trying prohibited operations (e.g., DROP TABLE) to confirm failures; audit credential rotation logs. - Monitoring signal: Repeated failed privilege escalation queries or successful unexpected DDL ops; alerts from DB audit logs for privileged statements.

**3) Container runtime capabilities & host access** - Apply: Drop Linux capabilities, run containers as non-root, enforce seccomp and AppArmor/SELinux profiles, restrict hostPath mounts. Use PodSecurityPolicies / OPA Gatekeeper. - Validate: Automated baseline scan (kube-bench, custom admission tests) ensuring capabilities list is empty and no privileged containers. Simulated exploit tests should fail to escalate. - Monitoring signal: Kube audit logs showing pods created with privileged=true, or abnormal use of CAP_SYS_ADMIN; runtime alerts for containers with host namespace access.

I would codify these controls in CI/CD policies, enforce reviews, and feed IAM/DB/container audit logs into SIEM to detect deviations.

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.