Get started · 20 minutes

Model your first story

1. Request your workspace. Choose a plan, name your workspace and give the admin's details. We set it up within one business day, and the admin gets an email to set a password and turn on multi-factor sign-in.
2. Set up the project. Upload a short intake document. SecureSprints drafts the project profile, and you confirm it.
3. Connect Jira. SecureSprints asks for read access only.
4. Start a story. Find a story in the sprint and start it. Triage proposes how deep to go, and you confirm.
5. Work through the stages. At each stage, confirm, answer an open question, or send it back with a change request.
6. Ask for approval. An Approver approves the model. Export the threat model report and the developer brief before anyone writes code.

SecureSprints never writes to Jira. Developers get their security tasks from the developer brief, the threat inventory or their coding agent.

Get started · once per project

Set up a project

A project profile tells SecureSprints what matters before it models any story. An owner or modeller creates it.

Intake document

A short description of business goals, systems, data and users. Upload it, or build the profile by conversation instead.

Project profile

Drafted by SecureSprints from the intake, then confirmed by a person. Any later change to a confirmed profile needs a second person to confirm it.

Code repository

Optional. A DevOps person or a lead proposes the connection, and an Approver confirms it. It is needed for the PR check and to link threats to code.

Get started

Connect Jira

SecureSprints reads stories from Jira and never writes to it. Personal and secret information is redacted from each story before any AI sees it.

Confirm integrations and scopes at launch

Model a story

Triage and the seven stages

Start one story or a batch. Each runs through triage, then the seven stages of PASTA, a published threat modeling method. SecureSprints stops for a person at every stage.

Full

A complete model, for new or high-risk work.

Delta

Only what changed, against what the project already knows.

Checklist

A shorter check for routine changes.

Not relevant

No model needed. Allowed only for low-risk kinds of change.

Triage also proposes what kind of change the story is, such as API, mobile, AI or LLM, cloud, or CI/CD. SecureSprints cross-checks the choice against the story. If the story mentions an API or an AI feature that triage left out, the choice must be fixed or explained.

At each stage you can confirm it, answer an open question, or send it back with a change request.

Model a story

Independent review and blocking findings

From stage 4 onward, an independent reviewer challenges the work before you can confirm it. It is a separate AI that works apart from the one drafting the model, and it can only report findings. It never edits the model.

A blocking finding, such as a wrong threat category, a wrong standard mapping or a gap in coverage, stops confirmation until the stage is fixed and reviewed again. A person can override it with a written reason. The override is recorded.

Verified

A reference checked against SecureSprints' built-in library of published standards.

Unlinked

A finding without a reference. It needs a reason.

AI-derived

An inference, stated as one, rather than something quoted from the story or the profile.

Invalid

A reference that isn't in the library. It is refused, even if it is correct.

Model a story · optional

Autopilot

A modeller can let SecureSprints confirm the low-risk stages on their behalf: business objectives, weakness analysis and attack modeling.

• It always stops for a person at triage, technical scope, decomposition, threat analysis and risk.
• It stops at any warning, open question or blocking review finding.
• Approval is always a person's.
• Every autopilot action is recorded under your name and marked autopilot.

Model a story

Approve and export

An Approver reads the assembled model and approves it, or sends it back to any stage. The approval is bound to the exact content, so a later edit needs a new approval.

• Threat model report, in HTML or Markdown, for reviewers and auditors.
• Developer brief: the security work as tasks a team or a coding agent can pick up, each with its test.

What the story taught joins the project baseline, so the next story starts from it.

Build and verify

The threat inventory and task statuses

Every approved threat lands in the project's threat inventory with its tasks. Each task is one security acceptance test.

Open

Approved, not yet scheduled.

Planned

Scheduled into a sprint.

In progress

Claimed by a developer or their coding agent.

Implemented

Done, with evidence attached, waiting to be verified.

Verified

Confirmed by CI test results, or by a lead who isn't the implementer.

Reopened

A test failed, or the code behind a verified control was removed.

Nobody verifies their own work. An Approver can accept a risk, with a reason, an owner and a review date, or mark a threat not applicable.

Build and verify · API on request

Send CI test results

Post test results from your pipeline. SecureSprints matches each result to the task whose test it names, and verifies the task when it passes.

curl -X POST https://acme.securesprints.ai/api/v1/test-results \
  -H "Authorization: Bearer $SECURESPRINTS_CI_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "commit": "9f2c4e1",
    "build": "1187",
    "test": "test_same_settlement_event_id_settles_once",
    "result": "pass"
  }'

The API is available to workspace admins on request: email hello@securesprints.ai. The request above is illustrative. CI tokens can only post test results. They can't read or change anything else.

Build and verify

PR check policies

With a repository connected, SecureSprints checks each pull request against the open threats it touches. Choose a policy per project.

Inform

A comment on the pull request lists the threats it touches.

Warn

The check is marked as a warning until the related tasks are addressed.

Block

The check fails until the related tasks are addressed, or an Approver accepts the risk.

If a pull request removes the code behind a verified control, the task reopens. A story whose threats are touched is suggested for a delta re-model.

Build and verify

Connect a coding agent

Developers can work through the threat inventory with their coding agent. The agent reads threats and developer briefs over a secure connection, set up from the project's Integrations page.

• It can claim a task and propose a fix.
• It can never mark a task verified. That comes from CI or a lead.
• Instructions found in code are never followed, and secrets are never read.

Confirm supported coding agents at launch

Administer · Program plan

Single sign-on and SCIM

Connect any SAML 2.0 or OpenID Connect identity provider, such as Microsoft Entra ID, Okta or Google Workspace. Turn on SCIM to create and remove members from your directory automatically.

1. Open Settings, then Identity. Copy the sign-on URL and entity ID.
2. Create the app in your identity provider. Paste the values and download the metadata.
3. Upload the metadata. Test with one account before you enforce single sign-on for everyone.