Preparing for a PSIRT interview? Practise explaining how you would take a vulnerability report from initial evidence to a validated fix and a clear customer advisory. Knowing a CVSS score helps; being able to defend your reasoning is what makes an answer useful.
In my own preparation, the most useful shift has been to separate what a scenario proves from what I would investigate next. This guide turns that approach into a repeatable framework for candidates moving from SOC, incident response or security engineering into product security.
By Amit Vijayan · September 6, 2026. These are original practice exercises and study notes, not a record of any employer’s interview questions.
What does a PSIRT do?
A Product Security Incident Response Team coordinates the handling of vulnerabilities in an organization’s products. Its work can include receiving reports, working with engineering to validate issues, assessing severity, coordinating remediation and communicating with researchers and customers. FIRST’s PSIRT Services Framework is a useful starting point for understanding this lifecycle.
For interview preparation, distinguish the product perspective from your operational response experience. A SOC investigation may ask whether an attacker compromised an environment. A PSIRT investigation also asks which product versions and configurations are affected, how engineering can remove the weakness, and what customers need to know. The teams can collaborate; their responsibilities depend on the organization.
A practical framework for PSIRT technical answers
I use the following sequence as a rehearsal tool. It keeps an answer structured without turning it into a memorized speech.
- Restate the evidence. Identify the affected feature, input, required access and observed behaviour. Separate confirmed facts from assumptions.
- Explain the mechanism. Trace attacker-controlled input into the vulnerable operation. Name the root cause before describing the consequence.
- Bound the impact. Establish the execution context and what data or service can actually be affected.
- Classify and score. Choose the most specific supported CWE and justify the CVSS metrics using the requested version.
- Validate safely. Describe a representative, authorized lab and the telemetry needed to confirm or reject your hypothesis.
- Fix and communicate. Address the underlying design, test the correction, identify affected releases and explain customer actions.
A useful sentence to practise is: “That is my initial assessment from the evidence provided; I would validate these assumptions before finalizing the impact and severity.” Follow it with the specific missing evidence. Uncertainty is useful when it produces a concrete investigation plan.
How to prepare for CVSS 3.1 and CVSS 4.0 questions
CVSS expresses vulnerability severity. A score alone does not tell you which issue a particular organization should address first. Explain the vector, then discuss exposure, exploitation evidence, customer impact and operational constraints separately.
CVSS 3.1: explain each decision
Practise Attack Vector, Attack Complexity, Privileges Required, User Interaction, Scope and confidentiality, integrity and availability impacts. Scope concerns a change in security authority; crossing a process boundary does not automatically establish it. Use the FIRST CVSS 3.1 specification to check definitions rather than relying on shorthand.
CVSS 4.0: do not translate the vector mechanically
Version 4.0 includes Attack Requirements and separates impacts to the vulnerable system from impacts to subsequent systems. It no longer uses the 3.1 Scope metric. Review the Base, Threat, Environmental and Supplemental metric groups in the CVSS 4.0 user guide. Supplemental metrics provide additional context without changing the calculated score.
For practice, explain what evidence supports each metric before opening the official calculator. Avoid guessing a decimal score from memory. Where the scenario leaves an important fact unresolved, state the assumption and show how a different answer could change the vector.
CVSS, EPSS and KEV answer different questions
- CVSS: how severe is the vulnerability under the scoring assumptions?
- EPSS: what is the estimated probability that a published CVE will be exploited in the wild in the next 30 days? See FIRST’s EPSS overview.
- CISA KEV: is the vulnerability listed as known to have been exploited? Use the Known Exploited Vulnerabilities Catalog as an input to prioritization.
An issue’s absence from KEV is not proof that it has never been exploited. In a prioritization exercise, I would also ask whether the affected component is reachable, enabled and used in a critical customer workflow.
Worked example: reasoning about OS command injection
Fictional practice scenario: an authenticated user can submit a value to a product’s diagnostics feature. Engineering confirms that the value reaches an operating-system command without adequate separation between data and command syntax. A harmless lab test causes an unintended command to run as the diagnostic service account.
1. Separate root cause, weakness and impact
- Root cause: unsafe construction of an OS command using attacker-controlled input.
- Weakness: OS command injection, consistent with CWE-78.
- Demonstrated impact: unintended command execution with the diagnostic service’s privileges.
“The attacker can execute commands” describes the consequence. It does not explain the programming error. Naming the unsafe operation makes the remediation discussion more precise.
2. Ask what the service account can actually affect
Before assigning high confidentiality, integrity and availability impacts, I would ask:
- Which sensitive files, secrets or records can the service read?
- Which data, configuration and executable files can it modify?
- Can it disrupt an essential service, and how complete or persistent is that disruption?
- What restrictions are imposed by its account, container, filesystem and network policy?
- Is there evidence of impact beyond the vulnerable system?
Do not claim privilege escalation, lateral movement or a complete takeover solely because command execution is possible. Those conclusions need evidence about the actual execution context.
3. Describe the evidence and reproduction plan
In an authorized isolated lab, first record normal diagnostic behaviour on an affected version and configuration. Then use a benign test that demonstrates the unintended execution without collecting secrets or disrupting service. Correlate the application request with process-execution telemetry, including the parent process, account and resulting activity. Record the exact conditions and the observation that distinguishes the vulnerable path from normal behaviour.
After remediation, repeat the test and verify that legitimate diagnostics still work. Include regression cases that exercise the unsafe input-handling pattern, not just one originally reported input.
4. Propose a fix that addresses the mechanism
Prefer eliminating shell-command construction in favour of an appropriate library or safe process-execution interface. Keep executable selection controlled, validate allowable arguments and run with least privilege. Passing arguments separately helps avoid shell interpretation, but does not automatically prevent unsafe options or argument injection; the called program’s behaviour still matters. MITRE’s CWE-78 guidance discusses prevention and mitigation approaches.
5. Deliver a concise interview answer
“The evidence supports OS command injection caused by unsafe command construction in the diagnostics feature. The demonstrated impact is command execution as the service account. I would establish that account’s access before finalizing the impact metrics, document the affected configuration, and correlate the request with process telemetry in a controlled lab. I would work with engineering to remove the unsafe execution pattern, then verify both the fix and normal diagnostic behaviour.”
PSIRT interview questions to practise
How would you handle an incomplete vulnerability report?
Explain what you can confirm, then request focused information: product and version, configuration, prerequisites, expected versus observed behaviour, reproduction steps and supporting evidence. Describe how you would track the case and keep the reporter informed. Avoid asking for a large, unfocused collection of logs.
How would you assess a denial-of-service report?
Trace the triggering input to the processing behaviour, constrained resource and observed service degradation. In your proposed lab, distinguish node-local failure from cluster-wide impact. Explain how you would observe recovery, failover and the effect on legitimate requests. Define limits and stop conditions before any load testing.
What if engineering disagrees with your severity assessment?
Walk through the disputed assumptions one metric at a time. Identify the observation that would resolve the disagreement and record the rationale. Discuss customer prioritization separately from the technical severity score. A defensible shared assessment is more useful than winning an argument over a number.
What belongs in a customer security advisory?
Cover the affected products and versions, prerequisites, impact, identifier where assigned, severity rationale, fixed releases, practical mitigations and update history. Distinguish confirmed facts from investigation status. FIRST’s PSIRT framework describes disclosure coordination and advisory responsibilities.
How would you coordinate disclosure?
Discuss communication with the reporter, engineering and relevant product stakeholders; a shared plan for remediation and publication; and how changing exploitation evidence would affect urgency. Avoid presenting a single deadline as universally correct. Practise explaining how you would handle dependencies or multiple affected vendors.
How does incident response experience help in PSIRT?
Bring a real example of evidence collection, competing hypotheses, prioritization or stakeholder communication. Explain your own contribution and the result. Then connect that experience to product investigation, fix validation or advisory writing. Use only details you are entitled to share.
A seven-day PSIRT interview preparation plan
- Day 1 — Map the role. Read the PSIRT framework and draw a vulnerability report’s path from intake to disclosure.
- Day 2 — Classify weaknesses. Pick three public advisories. Separate the root cause, CWE and demonstrated impact for each.
- Day 3 — Practise CVSS. Build vectors using the official definitions and calculator. Explain the assumptions aloud.
- Day 4 — Plan validation. Write a safe reproduction plan, required telemetry and pass/fail criteria for a fictional issue.
- Day 5 — Write an advisory. Summarize a public, already-fixed vulnerability in language a customer can act on.
- Day 6 — Rehearse collaboration. Prepare examples of resolving disagreement, working under uncertainty and communicating risk.
- Day 7 — Run a mock interview. Give a two-minute assessment, then let a partner challenge your assumptions. Revise the weak reasoning.
A final self-check before the interview
Can you explain the unsafe operation, the evidence supporting impact, the missing information, the validation method and the fix? Can you give a customer a clear next step? If you can do those things without relying on memorized claims, your preparation is moving in a useful direction.
For my professional background, visit About Amit Vijayan or connect with me on LinkedIn.
