security.txt Setup

Why It Matters

security.txt is the internet’s standard signal for “here’s how to report a security issue to us.” Defined in RFC 9116, it is endorsed by CISA and required of US federal agencies under Binding Operational Directive 20-01. Security researchers, vulnerability scanners, and government agencies automatically query /.well-known/security.txt when evaluating an organization’s security posture.

Publishing a valid security.txt signals that your program is legitimate and staffed. Absence signals the opposite — and increasingly raises flags with auditors and enterprise procurement teams.

Even on the free tier, Kit publishes security.txt automatically when you enable VDP. Zero configuration required.

What Is security.txt

A plain-text file served at /.well-known/security.txt over HTTPS. RFC 9116 defines six standard directives:

Directive	Required	Description
Contact	Yes	Email or URL where vulnerability reports should be sent
Expires	Yes	ISO 8601 datetime after which the file should no longer be trusted
Policy	No	URL to your full disclosure policy page
Acknowledgments	No	URL to your Hall of Fame or thanks page
Hiring	No	URL to your security team job postings
Encryption	No	URL to a PGP public key for encrypted communications

Kit also appends Preferred-Languages: en automatically.

A minimal valid file looks like this:

Contact: mailto:[email protected]
Expires: 2027-02-27T00:00:00Z
Policy: https://example.com/security/acme/.well-known/security.txt
Preferred-Languages: en

A fully configured file includes all six directives:

Contact: mailto:[email protected]
Expires: 2027-02-27T00:00:00Z
Policy: https://example.com/security/acme/policy
Acknowledgments: https://example.com/security/acme/hall-of-fame
Hiring: https://example.com/careers/security
Encryption: https://keys.example.com/pgp-key.asc
Preferred-Languages: en

Configuring security.txt

Navigate to VDP > Program Settings > security.txt. Configure the following fields:

Field	Default	Description
Contact Email	Account admin email	Used in the Contact: directive. Use a monitored security alias, not a personal inbox.
Policy URL	Auto-generated	Link to your disclosure policy page. Kit generates this from your program slug.
Acknowledgments URL	Auto-generated	Link to your Hall of Fame page. Kit generates this automatically.
Hiring URL	Blank	Link to your security team job openings. Optional.
PGP Encryption URL	Blank	URL to your PGP public key hosted externally. Optional.
Expiration Days	365	Number of days ahead the Expires: directive is set. RFC 9116 recommends no more than one year.

The Contact Email and Expiration Days are the only fields most programs need to change. Policy and Acknowledgments URLs are generated from your program configuration and update automatically.

Click Preview security.txt to see the raw output before saving. Saving any field triggers regeneration immediately.

Where It’s Served

Kit serves your security.txt at two URLs:

URL	When to Use
/security/{program-slug}/.well-known/security.txt	Kit-hosted — works immediately after enabling VDP
/.well-known/security.txt (your custom domain)	Production — requires custom domain setup in Account Settings

For custom domain serving, configure your domain in Account Settings > Custom Domains. Once configured, Kit serves /.well-known/security.txt at the root of your domain automatically. This is the URL you want researchers and scanners to discover.

The file is served with Content-Type: text/plain; charset=utf-8 per RFC 9116. Both URLs return identical content.

Auto-Regeneration

Kit handles security.txt lifecycle automatically:

• On config save — The file is regenerated immediately when any security.txt configuration field is saved. No manual publish step required.
• Expiration monitoring — A daily check monitors all published files for approaching expiration. When a file is within 30 days of its Expires: date, account admins receive an email with a direct link to renew.
• On renewal — Opening the security.txt settings page and saving (even without changes) regenerates the file with a fresh Expires: date calculated from today plus your configured Expiration Days.

An expired security.txt tells researchers your program may be abandoned. Kit’s expiration warning gives you a 30-day runway to renew before that happens.

Previewing the File

The Preview security.txt button in Program Settings renders the exact file content that will be served. Use it to:

• Verify the Contact: email is correct and monitored
• Confirm the Expires: date is set to the intended future date
• Check that Policy: and Acknowledgments: URLs resolve correctly
• Review any optional directives (Hiring, Encryption) before publishing

Preview reflects the current saved state. Make changes, save, then preview to see the updated output.

Validating Your Setup

After enabling VDP and configuring security.txt, verify it’s working:

1. Open https://yourdomain.com/.well-known/security.txt in a browser (or the Kit-hosted URL if you haven’t configured a custom domain)
2. Confirm the file renders as plain text with all expected directives
3. Verify the Expires: date is in the future and within one year
4. Check that the Contact: email or URL is correct
5. If using a custom domain, verify HTTPS is active — RFC 9116 requires the file to be served over HTTPS

External validators like securitytxt.org can parse your file and flag any RFC 9116 compliance issues.

Quick Checklist

• Enable VDP (security.txt is auto-generated at activation)
• Set your contact email to a monitored security alias (not a personal inbox)
• Verify /.well-known/security.txt resolves on your custom domain
• Set the Policy URL so researchers know the rules before submitting
• Confirm the Expires: date is no more than one year out
• Schedule a calendar reminder at 11 months to verify file hasn’t expired (or rely on Kit’s 30-day expiration warning email)

Next Steps

• Configuring Your Program — all program settings including scope, bounty matrix, and SLAs
• Vulnerability Disclosure Overview — what’s included with Free and the VDP Add-on