A security spike is a short story whose output is an answer, not a feature. Fix its length in hours or days before it starts, write the one question it must answer, and end it with a written decision. If the question is still open at the deadline, report that and decide what to do next.
What a spike is
A spike is an agile technique for investigating something unknown. The Scrum Guide does not define it, but it does say Developers decide how work is done and that work is broken into small items. A spike is one such item, with research as its result.
For security, spikes fit questions like "can we verify this webhook signature with our library?", "what data would this new integration receive?" or "what would it take to move this secret into a vault?"
When to use one
Use a spike when a story fails the "ready" check because nobody knows the answer, and guessing would risk building the wrong thing. Do not use one to avoid a decision that is already clear, or to hide a large piece of work under the word "research".
The spike card
Write these five lines on the card before work begins.
| Field | Example |
|---|---|
| Question | Can the new partner API authenticate with mutual TLS in our gateway? |
| Time box | 2 days, ends Thursday |
| Output | A one-page note and a yes, no or "yes with changes" |
| Done when | The note is linked in the follow-up stories |
| Not in scope | Building the integration |
Steps to run one
- Write one question. If you have three, you have three spikes.
- Set the time box in advance. Pick the shortest period that could answer it. Two days is common. Anything beyond a sprint is a project.
- Name who reviews the output. A spike nobody reads is wasted.
- Work to the question. Prototype only enough to answer it, and throw the prototype away or label it clearly.
- Stop at the deadline. Report what you learned, including "not answered".
- Create the follow-up stories. Link the note and write real acceptance criteria.
What good output looks like
A good result is short: the question, the answer, the evidence and the recommended next stories. It also lists the risks the investigation found, so the product owner can order them. Store it where the team looks, such as the story, not a private folder.
NIST's Secure Software Development Framework asks teams to record design review findings as artifacts, such as in the issue tracking system, so spike notes are a natural place to keep them. The Threat Modeling Manifesto and OWASP's cheat sheet frame risk work as an ongoing activity that feeds design, development and testing, which is what a spike does at small scale.
Pitfalls
- No end date. Without one, the spike grows into a project.
- Prototype shipped as production code. Treat spike code as disposable.
- No decision. If the note does not change the plan, the spike did not work.
- Using spikes for routine work. If the answer is known, just write the story.
A rule of thumb
If you can name the question and the end date, you can run the spike. If you cannot, split the problem or take it to a design review instead.
Safeguard offers dependency scanning and SBOMs, which can answer questions like "what does this library pull in?" during a spike. Try a free scan at gold.safeguard.sh/scan.
Quick check
How long should a security spike be?
As short as can answer the question, often one to three days, and never longer than a sprint. Set the end date before starting.
What if the spike does not answer the question?
Report that at the deadline with what you learned, then decide whether to run a second spike, escalate to a design review or change the approach.
Sources
- The Scrum Guide
- NIST SP 800-218, Secure Software Development Framework 1.1
- OWASP Threat Modeling Cheat Sheet
Last reviewed: 19 October 2026.
