Senior Penetration Tester Interview Preparation Guide - Spotify

Threat-modeling the pipeline itself, rather than the application it ships, means treating the pipeline as a genuinely privileged system in its own right, since it routinely holds the credentials needed to deploy to production and often runs code it doesn't fully trust.

Assets and trust boundaries

The key assets are: the source repository (what determines what gets built), the CI runners (which execute arbitrary build-defined code), the secrets and signing keys the pipeline holds, and the artifact registry and deployment target (the ultimate destination an attacker wants to reach). Trust boundaries sit wherever untrusted or less-trusted input meets a more-trusted execution context: an external contributor's pull request meeting a runner that has repository write access or secrets access is the sharpest boundary, since a malicious PR is attacker-controlled input running inside a context that may hold real credentials.

Likely attackers and top threats

A plausible attacker profile ranges from an external contributor submitting a malicious pull request, to an attacker who has compromised a legitimate contributor's credentials, to an attacker who has compromised a third-party dependency or CI action the pipeline trusts. The top five threats, roughly in order of how often they show up in real incidents: (1) runner compromise via a malicious build step, letting an attacker read whatever secrets that runner had; (2) supply-chain poisoning via a compromised dependency or third-party action; (3) a malicious pull request triggering a workflow with elevated permissions (the poisoned-pipeline-execution pattern, particularly via triggers like pull_request_target that grant a fork's PR access to secrets); (4) leaked long-lived credentials granting broader access than a short-lived credential would; (5) a compromised signing key letting an attacker produce artifacts that appear legitimately trusted.

Mitigations, prioritized by impact and effort

Highest impact, lowest effort: pin all third-party actions to an immutable commit SHA (addresses threat 2 directly, cheap to implement, no ongoing operational cost). Next: avoid or tightly restrict dangerous trigger patterns like pull_request_target for anything that doesn't strictly need it (addresses threat 3, requires an audit of existing workflows but no new infrastructure). Then: move to ephemeral, least-privilege runners and short-lived, scoped credentials (addresses threats 1 and 4, moderate effort since it may require re-architecting how credentials are issued). Highest effort, addressing the residual risk in threat 5: keyless, OIDC (OpenID Connect)-backed signing removes the long-lived signing key from the picture entirely, closing that threat at the cost of migrating existing signing infrastructure.

Trade-offs

Prioritizing by impact-versus-effort rather than tackling every threat with equal urgency means some real risk (the signing-key compromise threat) stays partially open longer, since it's genuinely the most expensive to fully close; that's an honest, deliberate sequencing choice rather than an oversight, made explicit so stakeholders understand exactly what residual risk remains at each stage of the rollout.

Direct answer: a JSON Web Token (JWT) is self-contained and verified locally with a signature check, fast, no network call needed, but hard to revoke early. An opaque token is a meaningless random string that must be looked up (introspected) against the issuing server on every use, slower and an added dependency, but instantly revocable by deleting it server-side.

Local verification versus introspection: a JWT's verifier checks its cryptographic signature against the issuer's public key locally, no network call per request. An opaque token carries no embedded meaning, so the verifier must call the issuing server's introspection endpoint to ask whether it is still valid, on every use.

Revocation: a JWT is hard to revoke before its natural expiry, since any verifier holding the issuer's public key validates it independently, options are keeping expiry very short, or maintaining a deny-list every verifier must also check, which erodes the "no network call" advantage. An opaque token is trivially revocable, delete or invalidate the record in the issuer's store and every future introspection call immediately reports it invalid.

Size and transport: a JWT is bigger, a header, a payload of claims, and a signature, all base64-encoded, and this adds up if it rides along on many internal calls. An opaque token is small, just an identifier, cheap to pass around.

When to prefer each: prefer JWTs when many verifiers need to check tokens fast and independently, without a hot-path dependency on a central auth server, and when the token's lifetime can be kept short enough that limited revocability is not a real risk. Prefer opaque tokens with introspection when you need to instantly kill a specific session or credential, a compromised account, a departed employee's access, or when you do not want token contents exposed to anyone who can read the token in transit or in logs.

Common JWT validation mistakes a reviewer should look for:

• Algorithm confusion: trusting the alg field the token itself claims instead of pinning the expected algorithm, this is how a server ends up accepting a token signed with none, or gets tricked into verifying a forged token using its OWN public key as if it were a shared secret.
• Missing audience (aud) check: without verifying the token was issued FOR this specific service, a valid token minted for one internal service can be replayed against a different service that trusts the same issuer.
• Missing or ignored expiry (exp) check: a technically expired token is still accepted because the timestamp claim is never checked.
• Missing or mismatched issuer (iss) check when multiple issuers are trusted: a token from a lower-trust issuer gets accepted where only a specific higher-trust issuer should be.

Worked example: a reviewer should specifically confirm the code hardcodes an expected algorithm, for example explicitly requiring RS256 rather than reading alg from the token, explicitly compares the aud claim against an expected value, and explicitly checks exp, rather than trusting a library's defaults without confirming what those defaults enforce. Library defaults on this have changed across versions and ecosystems, so "we used a JWT library" is not itself something you can verify without reading the actual validation call.

Trade-offs & pitfalls: teams sometimes treat "JWT" and "secure" as synonyms, an improperly validated JWT is not safer than an opaque token, it is often worse, because it looks cryptographically strong while actually accepting forged tokens. Long-lived JWTs adopted because "introspection was too slow" reintroduce the exact revocation problem opaque tokens exist to solve.

Direct answer: threat intelligence turns "is this being attacked right now, anywhere" into a concrete signal that can override a finding's static severity score. The three most practical sources are exploit databases (public proof-of-concept code), vendor security advisories, and active-exploitation reports (most notably a known-exploited-vulnerabilities catalog), and the common pattern is: a new signal arrives, it maps to a specific finding you already have open, and that finding's priority tier changes immediately rather than waiting for its next scheduled review.

Structured elaboration:

• Exploit databases and public proof-of-concept repositories tell you exploitation has moved from theoretical to trivially repeatable; once working exploit code is public, the realistic population of attackers who can use it expands from skilled specialists to anyone who can copy a script.
• Vendor advisories sometimes explicitly state "we have observed active exploitation of this vulnerability in the wild" as part of the disclosure, which is a much stronger signal than the vulnerability's severity score alone.
• Active-exploitation catalogs, most notably the Cybersecurity and Infrastructure Security Agency's Known Exploited Vulnerabilities (KEV) catalog, formalize this into a maintained list: an entry there means a government agency has independently confirmed real-world exploitation, and it's specific enough to trigger a policy rule automatically rather than needing a human to read every advisory.

Worked example: a finding started as a moderate-priority Common Vulnerability Scoring System (CVSS) 6.1 cross-site scripting bug, sitting comfortably in a normal-cadence remediation bucket. Weeks later it's added to the KEV catalog after evidence of active in-the-wild exploitation surfaces. Under a policy of "any KEV-listed finding is automatically escalated to the top remediation tier regardless of its original CVSS-only priority," that single signal moves it from the normal-cadence bucket straight to an urgent, short-deadline queue, without anyone needing to manually re-score the finding's severity, which never changed. The Cybersecurity and Infrastructure Security Agency itself models this pattern for United States federal civilian agencies, which are directed to remediate KEV-catalog entries by a due date the catalog assigns, typically within about two weeks of listing for confirmed actively-exploited vulnerabilities; many private organizations adopt an equivalent internal service-level agreement even though they aren't bound by that federal directive.

Trade-offs and pitfalls: the automatic-escalation rule only works if someone is actually watching these feeds and mapping new signals back to your open findings; a KEV listing that never gets ingested into your tracking system produces zero benefit no matter how good the policy sounds on paper. The other common failure is treating the absence of a threat-intelligence signal as proof of safety: a vulnerability with no public exploit yet and no KEV listing yet can still be exploited tomorrow, so this should raise priority on a positive signal, not lower it in the absence of one.

Direct answer

Start by scoping the problem precisely enough that ownership boundaries become visible, then build a coalition of every team whose work the fix touches rather than waiting for someone to volunteer ownership. Secure a sponsor with authority spanning those teams who can prioritize the fix against each team's other work, and sequence the remediation so early, low-risk wins buy the credibility needed to sustain a multi-month effort.

Structured elaboration

1. Scope with evidence. Document the pattern concretely enough, which systems or teams are affected and how you know, that it reads as a shared problem rather than one team's incident. Vague framing invites everyone to assume it is someone else's issue.
2. Coalition, not delegation. Identify every team whose systems or processes need to change and bring them into a kickoff where they see the evidence directly, rather than hearing about it secondhand from you.
3. Sponsorship. Find someone with authority spanning all the affected teams who can prioritize the fix against each team's existing roadmap. Without this, the effort re-competes for attention every sprint and eventually loses.
4. Phased roadmap. Ship interim mitigations that reduce risk within days to weeks, while the durable fix is designed and rolled out over the following weeks to months. The organization should not be fully exposed while waiting for the complete fix.
5. Communication rhythm. A lightweight, regular update, what is done, what is blocked, what is next, keeps the effort visible to the sponsor and affected teams over a multi-month timeline, instead of fading once the initial urgency wears off.
6. Closure and verification. Define what "done" looks like before you start, and verify it at the end. A systemic fix without a defined closure condition tends to drift indefinitely.

Worked example

Suppose the systemic problem is a class of vulnerability that recurs across several services owned by different teams (the same shape applies to a systemic reliability gap or an accessibility gap spanning many product surfaces). Six teams share the affected pattern. A kickoff is scheduled within the first week so all six see the evidence together. A low-risk compensating control is rolled out across all six teams within the first two weeks, buying time while the durable fix, a shared library or pattern change, is designed and rolled out over roughly two months. Progress is reported every two weeks to the sponsoring lead and the six teams. The effort closes only once every team has migrated to the durable fix and the compensating control has been verified safe to remove.

Trade-offs & pitfalls

• Trying to fix it yourself across every team's codebase does not scale past a handful of teams and burns out the person carrying it.
• Skipping interim mitigation and going straight for the durable fix leaves the organization exposed to the systemic risk for the entire multi-month build, a costly bet if anything slips.
• Junior candidates tend to focus on getting the technical fix right. Senior candidates weight the coalition and sponsorship just as heavily, because a correct fix with no organizational backing stalls the moment it competes with someone's sprint commitments.
• Not defining "done" is a common pitfall: an effort with no closure condition can run indefinitely, consuming goodwill and losing the sponsor's attention long before every team has actually migrated.

Direct answer: For a critical SQL injection in a decade-old legacy app, the right call is almost never a single option in isolation - deploy the WAF rule immediately as a stopgap while you patch the actual query, because the four options operate on completely different timescales and risk profiles, not as mutually exclusive choices.

Structured elaboration, option by option:

1. Immediate WAF rule. Pros: deployable in minutes, no code change, no regression risk to the application itself. Cons: a signature-based rule can be evaded (encoding tricks, comment injection, alternate syntax) and gives false confidence if treated as "fixed." Verification: confirm the specific payload that triggered the finding is now blocked, and test a couple of known evasion variants against the rule. Rollback risk: near zero - disabling a WAF rule is instant and doesn't touch application state.

2. Patch the query-string building. Pros: fixes the actual root cause; this is the only option on the list that structurally closes the vulnerability rather than reducing its likelihood of exploitation. Cons: requires a code change, a deploy, and regression testing on a decade-old codebase that may have thin test coverage around this code path. Verification: the exact reproduction steps from the vulnerability report should return the expected safe result after the fix (as demonstrated for the classic pattern: a parameterized version of a vulnerable query returns zero rows for an injection payload that previously leaked every row). Rollback risk: moderate - a badly-tested change to old, brittle code can introduce a functional regression, so this needs real test coverage or careful manual verification before it ships to production.

3. Migrate to an ORM, medium-term. Pros: prevents this whole CLASS of bug going forward across the codebase, not just this one query. Cons: a large, slow, high-risk undertaking on a decade-old app; doing this under incident pressure invites new bugs from a rushed migration. This is a program of work, not an incident response action. Verification: this needs its own testing program, not a quick check. Rollback risk: high if rushed - this is exactly the kind of change that should happen on a normal engineering cadence, not as part of the immediate incident response.

4. Isolate the app with network controls. Pros: reduces exposure (fewer things can reach the vulnerable endpoint) without touching the vulnerable code at all. Cons: doesn't fix anything if the attack surface is still reachable by legitimate users who need it; only genuinely useful if the app can be taken off the public internet or restricted to a smaller trusted network without breaking its actual purpose. Verification: confirm the network change doesn't also break legitimate traffic. Rollback risk: low, but "isolating" a production app that customers need to reach isn't always a real option.

Recommended phased plan: (1) WAF rule live within the hour as a stopgap, verified against the specific reported payload; (2) patched query shipped within days, with the specific exploit payload from the report added as a permanent regression test; (3) network isolation considered in parallel only if it doesn't disrupt legitimate use, as extra defense in depth while (2) is in flight; (4) ORM migration scheduled as its own project, informed by this incident but not rushed because of it.

Trade-offs and pitfalls: the single biggest mistake here is treating the WAF rule as the fix and closing the incident - it buys time, nothing more, and a determined attacker will eventually find the encoding variant it doesn't cover. The second biggest mistake is rushing the ORM migration under incident pressure; a decade-old codebase's untested corners are exactly where a rushed migration introduces a NEW, unrelated bug.

Direct answer

Attack surface analysis for a new, personally identifiable information (PII)-handling microservice is a discovery-then-prioritization exercise: enumerate everything that can be reached or influenced from outside the service's trust boundary, map how PII moves through it, and turn that inventory into a ranked list of what needs review before launch. The process below runs in five stages, uses different tooling at each stage, and needs specific people in the room, not just the security team, because attack surface is created by product and infrastructure decisions the security team doesn't always see.

Structured elaboration

Stage 1: scope and data classification

• What happens: confirm the service's boundaries (what it owns versus calls out to), and classify exactly which PII fields it touches (name, email, government ID, payment data all carry different regulatory weight).
• Tools: a data classification spreadsheet or a data catalog tool if the org has one; the service's Application Programming Interface (API) schema (OpenAPI/Swagger) as the starting inventory of what the service exposes.
• Artifacts: a scope document and a data classification table.
• Participants: the product owner (what does the feature do), the lead engineer (what does the service actually touch), and, if PII crosses a regulatory threshold, a privacy or legal contact.

Stage 2: interface and dependency discovery

• What happens: inventory every inbound interface (public endpoints, internal service-to-service calls, admin/debug endpoints, message queue consumers) and every outbound dependency (databases, caches, third-party APIs, the CI/CD pipeline that deploys it).
• Tools: the API schema again, a network/port scanner for what's actually listening (not just what's documented), the cloud provider's asset inventory (for example AWS Config or an equivalent), and the service mesh's own topology view if one exists.
• Artifacts: an asset and interface registry, ideally one that gets regenerated automatically rather than hand-maintained, since a hand-maintained inventory goes stale within a quarter.
• Participants: the lead engineer and a DevOps/platform engineer who knows the actual deployed topology, which frequently differs from the design doc.

Stage 3: data flow and trust boundary mapping

• What happens: draw where PII enters, where it's transformed, where it's stored (including caches and logs, which are the most commonly missed PII stores), and where trust level changes (public internet to load balancer, load balancer to internal network, service to third-party processor).
• Tools: a diagramming tool (draw.io, Lucidchart) or a dedicated threat modeling tool (OWASP Threat Dragon, Microsoft Threat Modeling Tool) that produces a structured data flow diagram (DFD) rather than a static image.
• Artifacts: a DFD with trust boundaries marked explicitly.
• Participants: lead engineer plus whoever owns the service the microservice calls out to, since trust-boundary decisions are often made unilaterally by one team but affect both.

Stage 4: threat identification and technical verification

• What happens: apply a threat-modeling method (STRIDE: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege is the standard starting point) against the DFD from stage 3, then verify the highest-concern items with targeted technical testing rather than assuming the design holds.
• Tools: STRIDE against the DFD; the OWASP Application Security Verification Standard (ASVS) as a checklist; API fuzzing and manual testing with Burp Suite or OWASP ZAP; static application security testing (SAST) and software composition analysis (SCA, dependency vulnerability scanning) run against the service's own repository.
• Artifacts: a threat log and a prioritized finding list with severity.
• Participants: security engineer running the testing, lead engineer to interpret findings against the real design.

Stage 5: operational and configuration review, then remediation planning

• What happens: check the things that don't show up in a DFD but create real attack surface anyway: whether PII leaks into logs, whether the service's identity and access management (IAM) role is broader than it needs, whether secrets are stored properly, whether encryption at rest is on. Then convert everything found into an owned, dated remediation backlog rather than a report nobody acts on.
• Tools: cloud IAM console/policy analyzer, secrets manager audit, log sampling for accidental PII exposure.
• Artifacts: a configuration checklist and a remediation backlog with owners and acceptance criteria.
• Participants: DevOps/SRE (owns the runtime configuration), QA (owns verifying the fix), and the original product owner (signs off that remediation doesn't silently break the feature).

Worked example

Take a concrete instance of stage 3 and 4 together: the microservice logs the full request body on error for debugging, and one field in that request body is the user's email address. Stage 3's DFD marks "logging pipeline" as a data flow most teams don't draw at all, because it feels like infrastructure rather than a feature. Stage 4's STRIDE pass against that flow flags Information Disclosure: the log aggregation system, which usually has broader read access than the production database itself, now holds PII outside the classification boundary set in stage 1. The fix (redact or omit PII fields before logging, and audit existing log retention for what's already there) only gets found because the process explicitly treats logging as an attack-surface component instead of leaving it implicit.

Trade-offs and pitfalls

The most common failure mode is treating this as a one-time exercise: an attack surface inventory produced at launch is accurate for exactly as long as nobody ships a new endpoint, which for an actively developed microservice is measured in weeks. The process above should feed a lightweight recurring check (ideally automated discovery re-run on each deploy) rather than a document that's filed away. A second pitfall is running stage 4's testing before stage 2 and 3 are actually complete; testing against an incomplete interface inventory reliably misses the exact debug or admin endpoint that turns out to be the real risk, because those are the ones least likely to appear in the official API schema. Finally, skipping the cross-functional participants in stages 1 and 3 to save time is a false economy: the security team alone usually cannot see which fields are actually PII under the applicable regulation, or which internal call the platform team quietly added last sprint, and both of those gaps show up as attack surface the model missed.

Direct answer

Mentoring is voluntary, growth-oriented influence without formal accountability. Managing includes formal accountability, resourcing decisions, and real consequences. The line moves the moment a mentee becomes a direct report, because feedback that used to be optional advice now carries formal weight, and the relationship gains structural power (comp, promotion, performance record) it didn't have before.

Where the line actually is

What changes when a mentee becomes a direct report

Private growth conversations now double as input to a formal review, whether that's said out loud or not. Advice that was previously optional is now, in practice, expected to be acted on for role reasons. The relationship carries real structural power (comp, promotion, PIP, short for performance improvement plan: the formal HR process for addressing underperformance) that it didn't have as informal mentoring. The hardest part is that "helping you grow" and "evaluating you" now happen with the same person, often in the same conversation, and separating those framings requires being deliberately transparent about which one is active at a given moment, rather than assuming the mentee can tell.

Worked example

A mentee who'd been mentored informally for a while later became a direct report after a reorg. The explicit adjustment made on day one: naming that some future 1:1 time would now include performance topics, not only growth topics, and being upfront about which kind of conversation was happening in the moment, rather than letting the mentee guess which hat was on.

Trade-offs and pitfalls

A common mistake is continuing to run the relationship exactly as before once it becomes formal, without naming the shift, which reads as inconsistent or even manipulative once the mentee realizes "informal advice" now affects their review. A stronger approach names the shift explicitly rather than letting the mentee discover it the hard way. Another pitfall is using "I'm just mentoring you" framing to soften what is actually a directive, formal expectation, which blurs accountability for both sides.

Overview
Below are six executive KPIs to measure control effectiveness across SOX/HIPAA from a penetration tester’s perspective. Each KPI maps to control families, has thresholds/escalation, and lists raw data sources + transformations (pentest findings + monitoring telemetry).

1. Mean Time to Remediate Critical Findings (MTTR-C)

• Control families: Change Management, Vulnerability Management
• Threshold: ≤ 14 days; Yellow: 15–30d; Red: >30d → Escalate to CISO + weekly exec report
• Raw data: Pentest reports (severity, discovery date), ticketing system ( remediation date )
• Transform: join findings by ID → compute days between discovery and remediation → filter critical

2. Percentage of Critical Controls Validated by Tests

• Control families: Access Controls, Audit Trails, Logical Security
• Threshold: ≥ 95% validated; Yellow 80–95%; Red <80% → Escalate to audit lead
• Raw data: Test plan matrix, pentest coverage logs, control catalog
• Transform: map tests to control IDs → compute validated controls / expected controls

3. Exploitability Rate of Open Findings

• Control families: Vulnerability Mgmt, Secure Config
• Threshold: ≤ 10%; Yellow 11–25%; Red >25% → Escalate to remediation owners
• Raw data: Pentest proof-of-concept status, CVSS, exploitability metadata
• Transform: flag findings with working exploit → ratio = exploits / open findings

4. Detection Rate of Simulated Attacks

• Control families: Monitoring & Logging, Incident Response
• Threshold: ≥ 90% detections; Yellow 70–89%; Red <70% → Escalate to SOC mgr
• Raw data: Red-team alerts, SIEM alerts, telemetry (IDS, EDR)
• Transform: correlate simulated attack timeline with SIEM/EDR alerts → compute detection %

5. False Positive Rate in SOC Triage

• Control families: Monitoring, Access Reviews
• Threshold: ≤ 20%; Yellow 21–40%; Red >40% → Escalate to SOC process owner
• Raw data: SOC tickets, pentest indicators (ground truth), telemetry
• Transform: tag triaged alerts against validated pentest indicators → FP / total alerts

6. Percentage of Controls with Compensating Controls Documented

• Control families: Governance, Risk Assessment
• Threshold: ≥ 98% documented; Yellow 90–97%; Red <90% → Escalate to compliance lead
• Raw data: Control registry, pentest findings that bypass primary controls, documentation repo
• Transform: identify controls failed in pentest → check for documented compensating controls → compute coverage

Reporting considerations:

• Update cadence: weekly for operations, monthly for execs
• Visuals: trend lines, heatmaps by control family, drilldowns to findings
• Quality controls: normalize severity taxonomy, canonical control IDs, automated ETL from pentest CSVs, SIEM exports, ticket APIs.

Direct answer

Reports mostly fail because they were written to prove the tester's work rather than to help a specific reader act. The recurring causes are below, each paired with a change to how I work.

Worked example: one finding, before and after

Before: "Cross-site scripting exists in the application." (Cross-site scripting, XSS, means an attacker gets their own script into a web page so it runs in other users' browsers. "Stored" means the site saves the script and serves it to later visitors.)

After: "Stored XSS on /profile (name field): an attacker saves a script in their display name; it runs in the browser of any staff member who opens their profile, which lets the attacker act as that staff member. Steps: (1) set name to the test string, (2) open the profile as a second user, (3) observe the script run. Fix: encode output on render. Owner: web team. Due: 30 days (high)."

The second version names impact, proof, fix, owner and date. The reader can act without a follow-up call.

Pitfalls

• Trying to fix all nine at once: pick the two that hurt your readers most and measure whether questions back to you drop.
• Treating "report delivered" as the finish line rather than "finding closed".

Direct answer. Use STAR (Situation, Task, Action, Result) and put most of the time on Action: how you changed the message for this audience. Sample shape below, to be replaced with your own story.

Situation. A routine review found that a storage bucket holding customer exports had been publicly readable for about two weeks. No evidence of access yet, but our logs only covered part of the period.

Task. Brief the CEO and General Counsel the same afternoon. They needed to decide whether to notify customers and whether to delay a partner launch that week.

Actions

• Led with the decision and the facts we knew. First line: "We found a data exposure. We have closed it. We do not yet know if anyone took data. I need two decisions from you today."
• Separated known, unknown and next check. Known: exposed for 14 days, now closed. Unknown: whether it was accessed. Next: log review done by 9am tomorrow.
• Kept jargon out and gave options. Wait for the log review before notifying, or prepare the notice now to send quickly if needed. I recommended preparing now. Legal would decide whether notification was legally required; I did not make that call.
• Stayed calm under pressure. I did not speculate, and I committed to a time for the next update.

Result. Leadership approved preparing the notice and holding the partner launch by one day. The log review found no sign of access in the part of the period the logs covered. Because that left a gap, I reported it as 'no evidence of access, not proof of none', and Legal decided that a notice was not required; so none went out, and the review of storage settings became a standing monthly check. A measurable outcome to cite is the decision time (same day) and the control added.

What I learned. Bad news lands better when it arrives with a recommendation and a time for the next update. The mistake to avoid is burying the headline in background.