Tuttify Carbon · Security

Threat models that don't get watered down. Even with a softer cue in the mix.

Tuttify Carbon runs an independent security intensity dial alongside the compliance dial — so a FedRAMP build doesn't get its threat model softened by a milder cue in the mix, and a Section 508 run doesn't get burdened with STRIDE depth it doesn't need.

Standard
STRIDE
6-axis threat taxonomy
Standard
ASVS L1–L3
OWASP verification depth
Artifact
Threat model
Per-component decomposition
Artifact
Risk register
CSV · audit-shaped
STRIDE coverage

Six axes. Every component. Mapped.

Carbon's threat-model writer decomposes the system into trust boundaries, then walks each component through the STRIDE taxonomy — spawning mitigation candidates, residual risks, and verifiable acceptance criteria.

S · Spoofing
Identity authenticity

Authn factors, identity-provider trust chain, session-binding requirements. Maps to NIST SP 800-63 AAL levels when the cue is FedRAMP.

T · Tampering
Integrity of data & code

Signed artifacts, immutable audit log, supply-chain controls. Hash-chained history is one of the answers.

R · Repudiation
Non-repudiation

Per-actor audit events, signed user actions, tamper-evident logging keyed to the regulatory cue's retention horizon.

I · Information disclosure
Confidentiality

Data-classification ladder, encryption-in-use posture, PHI/PII boundary calls. HIPAA cues inflate this section automatically.

D · Denial of service
Availability

Rate-limit envelopes, regional failover, dependency saturation. RTO/RPO are derived from intake — not hand-typed.

E · Elevation of privilege
Authorisation boundary

Role decomposition, least-privilege checks, lateral-movement abuse cases. CJIS and ITAR cues add criminal-misuse scenarios.

ASVS verification depth

Pick the level. Inherit the controls.

OWASP ASVS L1, L2, and L3 are first-class settings on the security dial. Each level imports a fixed set of verification controls into the acceptance criteria — not pasted as boilerplate, but interleaved with the requirements they verify.

L1
Opportunistic threats

For applications where compromise is inconvenient but not catastrophic. Default for low-risk internal tools and marketing surfaces.

L2
Targeted threats

The Carbon default for production SaaS handling sensitive data. SOC 2 and ISO 27001 cues land here.

L3
Advanced & sustained threats

For systems where compromise has direct safety, financial, or criminal consequences. FedRAMP, HIPAA, ITAR cues force this floor.

Where the two pillars overlap

Compliance frames the what. Security frames the how.

Compliance says "encrypt PHI at rest." Security says "AES-256-GCM with envelope keys, rotated quarterly, with HSM-backed master keys." Carbon writes both layers — and links them, so the auditor sees the control and the implementation in the same scrollable view.

Cue
Compliance writer
Threat-model writer
Overlap output
HIPAA
PHI handling sections, BAA scope, breach response (164.408 / 164.410).
PHI exfiltration abuse cases, healthcare-specific attack chains.
PHI-encryption acceptance criteria, linked to 164.312(a)(2)(iv).
FDA SaMD
IEC 62304 software lifecycle docs, ISO 14971 risk file, 21 CFR 820 design controls, SBOM.
Premarket Cybersecurity threat model per FDA 2023 guidance. Patient-safety abuse cases on every network surface.
Software safety classification (Class A/B/C) drives verification depth in the DHF.
FedRAMP / NIST
800-53 control mappings, evidence stubs by control family.
FIPS-validated crypto requirements, supply-chain abuse cases.
FIPS-mode posture statement linked to SC-13 control narrative.
PCI-DSS
CDE segmentation diagram, scope statement, SAQ shape.
Cardholder-data attack tree, tokenisation evasion paths.
Per-segment encryption + key-management posture, linked to 3.5/3.6.
ISO 42001
AIMS scope, AI-impact assessment, lifecycle responsibility map.
Prompt-injection & model-evasion threat sections, training-data poisoning chain.
ai-governance.md cross-linked to threat-model §AI surface.
CJIS / ITAR
Personnel screening, jurisdictional handling, audit cadence.
Insider-threat models, criminal-misuse scenarios, lateral movement.
Privileged-access acceptance criteria, traceable to a named CJIS policy area.
Security artifacts produced

The threat model is a deliverable. Not a slide.

Carbon produces structured security artifacts that read as engineering documents — not as marketing decks. Every section is keyed to a component, a control, and a verification step.

STRIDE
threat-model.md

Component decomposition, trust boundaries, per-axis threats, mitigations, residual risks.

Attacker payload
§ Attack chains

Framework-specific attack-chain sections appended by the threat-model writer when high-risk cues are present.

Risk register
risk-register.csv

Per-risk: owner, likelihood, impact, residual posture, treatment path. Filterable by control family.

ASVS
§ Verification matrix

Each requirement is annotated with the ASVS verification control that proves it — at the chosen depth.

Hash-chained
history.log

Tamper-evident event log. Any post-export modification is detectable with one command.

Per AI cue
ai-governance.md

Spawned when ISO 42001 or NIST AI RMF is ticked. Cross-linked to the AI surface of the threat model.

Show the work

When Carbon doesn't know, Carbon says so.

Confident-looking output without sourcing reads as fabrication — and reviewers smell it instantly. Carbon is engineered to surface uncertainty rather than paper it over.

Awaiting review

When a section is not yet ratified at a gate, Carbon labels it explicitly — never "complete" by silence.

Override authority — not yet captured

When the human responsible for an override is undefined, Carbon refuses to write a name — and surfaces the missing field in the gate review.

Provenance · low confidence

When the constraint grounder can't trace a requirement to a source, the provenance pill goes dim — and the audit diff flags it at G4.

Platform trust · Carbon itself

Your environment. Your model. Your seal.

Everything above is about the artifacts Tuttify Carbon writes for your build. This section is about Carbon itself — where your data lives, which model produces the prose, and what we won't ask you to take on trust.

Carbon is currently in customer trials across regulated verticals. Our own attestation program is in active development. Talk to us about your procurement window — we'll be straight about what's signed today and what's in flight.

Deployment
Customer-environment install

Carbon runs in your VPC, private cloud, or on-prem. Intake answers, uploaded artifacts, and generated bundles never leave the perimeter you control.

Model isolation
Bring your own LLM

Carbon does not host inference. Wire it to Azure OpenAI, AWS Bedrock, GCP Vertex, or your internal model server. The prose-writing surface is yours.

Tenancy
Per-project isolation

Every project sits in its own file tree. No cross-project context bleed. The hash-chained log is local to the project.

In flight
SOC 2 · BAA · ISO 27001

Our own attestation program is under active development as Carbon scales out of trials. We'll publish each milestone the day it's signed — and tell you exactly where we are when you ask.

Bring us a threat model

Send us your threat model. We'll send back ours.

Send us your existing threat model. We'll run the same scope through Carbon and you can compare — coverage, specificity, traceability, and how the package holds up against your control mappings.