Dark launching is safe only if hidden code gets the same security checks as visible code. Code behind a flag is still deployed, still reachable by anyone who can trigger the flag or call the endpoint, and still carries its dependencies. Treat deployment as the risk event, not release.
What dark launching is
DORA's small batches page describes it this way: developers start at the service or API layer, check completed small batches into trunk, and launch to production without making the changes visible to users. It is a way to keep batches small and merge daily without exposing unfinished features.
That is good for delivery. For security it moves the moment of risk. The code is in production long before users see it.
What can go wrong
- Unauthenticated endpoints. A new API route added ahead of the UI may be reachable directly, even though no page links to it.
- Missing authorization. A flag decides whether the feature appears, not whether a caller may use it.
- New dependencies. A package added for the hidden feature is deployed with every known flaw it carries.
- Debug paths left on. Test settings that were fine behind a flag can leak data once it flips.
- Flag state itself. If flags can be changed by a broad group, turning on an unreviewed feature is a release without review.
A checklist for flagged features
| Check | Question |
|---|---|
| Authentication | Does every new route require identity even with the flag off? |
| Authorization | Is access checked in the route, not only in the UI? |
| Dependencies | Did the change pass the same dependency checks as other code? |
| Data | Does hidden code touch real data before launch? |
| Flag control | Who can change the flag, and is it logged? |
| Rollback | Can the flag be turned off fast, and has anyone tested that? |
| Cleanup | Is there a date to remove the flag and dead code? |
Steps
- Run the normal pipeline checks on every flagged change. Do not exempt it because it is hidden.
- Add a short flag review step before the first exposure to any user, covering the checklist.
- Restrict who can change production flags, and keep an audit trail.
- Set an expiry for each flag in the ticket.
- Review long-lived flags monthly. Old flags are a form of debt.
How it shows in metrics
Dark launched code changes how you read DORA's lead time, which ends at deployment to production, not at user exposure. A feature may be counted done long before anyone uses it. If you care about exposure, add a separate measure: time from deployment to full release, so hidden code does not sit unreviewed indefinitely.
Quick check
Does a feature flag count as a security control?
No. A flag controls visibility. Use authentication and authorization to control access.
Should flag changes need approval?
For production features that touch sensitive data or permissions, yes. A lightweight review and a log are enough for most others.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how endpoints are tested whether or not a page links to them.
How Safeguard fits
Safeguard offers dependency scanning and policy gates for every change, flagged or not, plus asset discovery to find what is deployed. Try a free scan at gold.safeguard.sh/scan.
Sources
- DORA, Working in small batches (dark launching): https://dora.dev/capabilities/working-in-small-batches/
Last reviewed: 19 October 2026.
