Prompt and scope
This general interview question tests whether you can place a small public file inside a complete security-operations workflow. The point is not to recite fields; it is to connect the reporting entry point, authorization boundary, response ownership, and policy promises.
What the interviewer is assessing
- Whether you know RFC 9116's
/.well-known/security.txtlocation and required fields. - Whether you can distinguish discovery, validation, coordinated disclosure, and emergency response.
- Whether you avoid publishing an unattended mailbox, a private key, or an unowned response-time promise.
- Whether you can design on-call ownership, tickets, deduplication, and status updates that make the entry point work.
Clarifying questions to ask
First confirm which domains and products are in scope, whether several teams own the assets, whether third-party hosted assets are accepted, who is on call for each channel, which tests are authorized, and whether a vulnerability-disclosure policy already exists. Also clarify whether the goal is discoverability only or also rewards, encrypted submissions, and coordinated-disclosure dates.
A 30-second answer framework
I would publish a UTF-8 plain-text file at /.well-known/security.txt over HTTPS for each public asset. I would maintain a valid Contact and a future Expires, then add Policy, Canonical, Encryption, or Acknowledgments only when those processes really exist. The file only helps a researcher find the entry point; the backend still needs authorization scope, on-call ownership, tickets, deduplication, severity assessment, and safe status communication. Before launch I would verify HTTPS, expiry, link permissions, and the responsible rotation.
Step-by-step solution
1. Define the assets and entry-point boundary
List the primary domain, product domains, and high-risk APIs that need coverage instead of placing one file only on a marketing homepage. Contact should point to a mailbox or HTTPS form that can actually process reports; an unattended personal mailbox should not be the only route. If different teams own the assets, document how the report is routed.
2. Populate and continuously validate the RFC 9116 fields
Contact and Expires are required; Expires must express a future expiration time. Policy can link to authorized testing and disclosure rules, Canonical can identify the canonical file, Encryption belongs only when a maintained public key exists, and Acknowledgments or Hiring are optional. Serve the file at HTTPS /.well-known/security.txt as text/plain, without relying on HTML rendering.
3. Connect the file to the response workflow
When a report arrives, create an unpredictable ticket identifier and record receipt time, asset, reproduction steps, and the researcher's communication preference. The on-call person first checks authorization scope, then deduplicates, assesses impact, and assigns an owner. High-risk reports enter an emergency path; normal reports use the regular queue, with an audit trail for both.
4. Write a disclosure policy instead of inventing an SLA
The policy should explain permitted research, prohibited behavior, safe transfer of sensitive material, rewards if any, when public disclosure is allowed, and how good-faith testing is handled. Put only sustainable acknowledgment times and update rhythms in writing. Do not interpret an RFC field as a promise that every report will be fixed within a particular number of hours.
5. Protect the entry point and report data
The public file should not contain private keys, internal hostnames, personal phone numbers, or unpublished incident details. Limit attachment types and sizes, restrict access to mail and ticket systems, and treat scripts and links in the raw report as untrusted input. The security team may keep richer internal context, while replies to the reporter disclose only approved facts.
6. Prove that the entry point works with observability
Monitor the file's 200 response, HTTPS certificate, time to Expires, on-call rotation, and form-to-ticket conversion. Use harmless test reports to verify alerts, deduplication, and escalation; never use a real vulnerability for a drill. Check that CDNs, redirects, and multi-region deployments do not serve an old or expired copy.
High-quality sample answer
I would first list the public domains that need coverage and publish a UTF-8 plain-text file at HTTPS /.well-known/security.txt for each one. Contact would point to a staffed mailbox or form, while Expires would be set in the future and covered by an expiry alert. I would add Policy, Canonical, or Encryption only when those processes and keys are maintained. The file would not promise a repair deadline; the policy would state authorized scope, prohibited behavior, sensitive-material transfer, rewards, and coordinated disclosure. Reports would enter a restricted ticket system for scope checking, deduplication, severity assessment, and ownership, with an emergency path for high-risk cases. I would verify HTTPS, caching, permissions, on-call coverage, and renewal before launch, then monitor reachability, ticket conversion, and response states. The file makes the channel discoverable; the workflow and ownership provide the security capability.
Common mistakes
- Creating the file without an on-call owner, ticket queue, or escalation path.
- Omitting
Expires, leaving researchers with contact information that may no longer work. - Publishing a private key, internal address, or personal phone number.
- Promising a repair SLA, reward amount, or disclosure date the team cannot sustain.
- Replacing a stable HTTPS entry point with HTTP, a login redirect, or a stale CDN copy.
- Publishing reproduction details before authorization and impact have been checked.
Follow-up questions and responses
Can security.txt replace a vulnerability-disclosure policy?
No. It helps researchers discover Contact and Policy links; authorization scope, good-faith testing, rewards, disclosure coordination, and emergency rules still belong in the policy.
Why is Expires needed?
Contacts and processes change. Expires lets automated checks identify a file that may be stale so the team updates it instead of leaving an old mailbox looking valid indefinitely.
What if a group has many product domains?
Publish the corresponding file for each independently owned domain and use Canonical or policy links to explain the authoritative source. Every entry point still has to reach a team that can route reports; copying an unattended address is not enough.
What is the first step after a researcher reports a suspected zero-day?
Restrict access to the report, confirm the source and asset scope, record time and evidence, and notify the security owner for an emergency impact assessment. Do not forward unverified details to a public channel or ask the researcher to expand testing just to make the report more complete.