Reference → security.txt — file content + deploy spec

security.txt — file content + deploy spec

security.txt is a small text file at a standard well-known path that tells security researchers how to contact us when they find a vulnerability. It is defined by RFC 9116 and is increasingly expected by responsible-disclosure tooling and security researchers.

This file is a quick win for SGEN's security posture: low engineering effort, high signal to researchers, supports the Trust and Security page.

File location

The file must be served at both of these URLs (Cloudflare-style "well-known" + legacy):

  • https://sgen.com/.well-known/security.txt (preferred)
  • https://sgen.com/security.txt (fallback for tools that haven't adopted .well-known/)
Content-Type: text/plain; charset=utf-8

File content

# SGEN security contact# Generated: 2026-05-19# Format: RFC 9116Contact: mailto:security@sgen.comExpires: 2027-05-19T00:00:00.000ZPreferred-Languages: enCanonical: https://sgen.com/.well-known/security.txtPolicy: https://sgen.com/trust#reporting-a-security-issue

That is the entire file. No leading or trailing blank lines beyond what is shown.

Field meanings

  • Contact: the email address security researchers should use to report vulnerabilities. We use security@sgen.com (CREATE if missing).
  • Expires: the date at which this file should be re-issued and re-signed. RFC 9116 requires this field. We set it to one year out; bump on each re-deploy.
  • Preferred-Languages: en (English).
  • Canonical: the canonical URL of this file, used to detect tampering or out-of-date copies.
  • Policy: a link to our vulnerability disclosure policy. We point at the Trust page's "Reporting a security issue" section.

Optional fields (skip for now)

  • Encryption — public PGP key URL. Skip unless researchers ask for an encrypted channel.
  • Acknowledgments — URL listing researchers we've credited. Add when we have any.
  • Hiring — URL to security careers. Skip unless we have a dedicated security hiring page.

Signing (recommended but not required)

RFC 9116 recommends signing security.txt with a PGP signature so researchers can verify authenticity. The unsigned version above is acceptable for v1. If we later publish a signed version, the file becomes:

-----BEGIN PGP SIGNED MESSAGE-----Hash: SHA512Contact: mailto:security@sgen.comExpires: 2027-05-19T00:00:00.000Z... etc...-----BEGIN PGP SIGNATURE-----... signature...-----END PGP SIGNATURE-----

We would need a security PGP key and a public-key URL (Encryption field) to do this. Defer until we have a security team.

Renewal cadence

  • Reissue annually (bump Expires).
  • Reissue immediately if the Contact email changes.
  • Reissue immediately if the Trust page URL or path moves.
A calendar reminder for the renewal date (one year from publish) is the simplest mechanism.

Verification after deploy

Open both URLs in any browser:

  • https://sgen.com/.well-known/security.txt (canonical location per RFC 9116)
  • https://sgen.com/security.txt (legacy fallback)
Both should display the file content as plain text. Validate format against an RFC 9116 validator (any current online tool) — paste the URL, confirm format passes.

Internal deploy + curl-based verification spec lives at _internal/security-txt-deploy-spec.md (engineering).

Response commitment

SGEN acknowledges vulnerability reports submitted to security@sgen.com within 10 business days. The acknowledgement confirms receipt and provides a tracking reference. Subsequent updates depend on severity and complexity of the reported issue and are communicated as investigation progresses.

The 10-business-day ack window mirrors the accessibility-report ack window for operational consistency. Researchers who do not receive an acknowledgement within that window should re-send to legal@sgen.com as a fallback.

Linkage

  • Trust and Security page references security@sgen.com for reports. Keep these in sync.
  • Privacy Policy Section 9 ("Security") may reference /.well-known/security.txt once published.
On this page