💻 computer science

Architecture-Derived CBOMs for Cryptographic Migration: A Security-Aware Architecture Tradeoff Method

This paper introduces SATAM, a security-aware architecture tradeoff method that integrates established frameworks like ATAM and STRIDE to derive context-rich, architecture-grounded Cryptographic Bills of Materials (CBOMs) that enhance cryptographic migration planning by capturing essential security intent and rationale missing from traditional inventory-based approaches.

Original authors: Eduard Hirsch, Kristina Raab

Published 2026-03-25

📖 5 min read🧠 Deep dive

CC BY 4.0

Original authors: Eduard Hirsch, Kristina Raab

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

The Big Problem: The "Mystery Box" of Encryption

Imagine you own a massive, high-tech fortress (your software system). Inside this fortress, you have hundreds of different locks, keys, and secret codes (encryption) protecting your treasure.

For years, you've been using these locks. But now, the world is changing:

Old locks are breaking: Hackers are finding ways to pick them.
New rules: The government says, "You must use these specific locks."
Future threats: A super-weapon (Quantum Computers) is coming that will break all current locks instantly.

You need to swap out every single lock in your fortress. This is called Cryptographic Migration.

The Problem: Most companies try to do this by just making a list of every lock they own (a "Bill of Materials"). It's like a grocery list: "We have 50 padlocks, 20 deadbolts, and 10 combination safes."

But a grocery list doesn't tell you:

Why you put that specific lock on the vault door instead of the back gate?
What would happen if you swapped that lock for a different one?
Who is responsible for changing it?

Without knowing the "Why" and the "What if," changing the locks is dangerous. You might accidentally leave the vault door unlocked or break the door frame because the new lock doesn't fit.

The Solution: SATAM (The "Architect's Detective")

The authors of this paper propose a new method called SATAM (Security-Aware Architecture Tradeoff Analysis Method).

Think of SATAM not as a list-maker, but as a detective who interviews the building's original architect.

Instead of just counting the locks, SATAM goes back to the blueprints and asks:

"Why did you choose this specific lock for this door?"
"What kind of thief were you trying to stop?"
"If we change this lock, does it weaken the whole wall?"

SATAM takes the existing "Architectural Blueprints" and turns them into a Super-List (an Architecture-Derived CBOM). This Super-List doesn't just say what the lock is; it explains the story behind the lock.

How SATAM Works (The 4-Step Recipe)

The paper describes a process that mixes several existing tools into one powerful workflow. Here is the analogy:

1. The Blueprint (Arc42)

First, you look at the architectural drawings of your software. You identify where the "Trust Boundaries" are (where the outside world meets your inside world).

Analogy: You walk through the fortress with a flashlight, marking exactly where the walls are and where the doors are.

2. The Villain List (STRIDE)

Next, you imagine all the ways a bad guy could attack. The paper uses a method called STRIDE to categorize these attacks (like Spoofing, Tampering, or Repudiation).

Analogy: You hire a team of "Red Team" actors to try to break in. They shout, "I can pick this lock!" or "I can sneak in through this window!" You write down every specific threat.

3. The Rules of Engagement (Security QAS)

You turn those threats into strict rules. Instead of saying "Don't let them break in," you say, "If someone tries to tamper with the data, the system must reject it within 1 second."

Analogy: You write the "Rules of the Fortress." "If a door is forced, it must slam shut automatically."

4. The Decision Log (ADRs)

This is the most important part. When you decide which lock to use to satisfy those rules, you write it down in a Decision Record (ADR).

Analogy: You write a note: "We chose the Titanium Deadbolt for the Vault because it resists the 'Pick' attack mentioned in Rule #4. We rejected the 'Wooden Latch' because it's too weak."

The Magic Result: The "Smart" Inventory

Once SATAM finishes its work, it produces a CBOM (Cryptographic Bill of Materials) that is different from any other.

Old CBOM: "We use AES-256 encryption." (Boring. Useless for planning.)
SATAM CBOM: "We use AES-256 on the Database connection because:
1. It stops 'Tampering' (STRIDE Threat).
2. It meets the '1-second rejection' rule (QAS).
3. We chose it over RSA because it's faster for this specific door (ADR).
4. Warning: If we switch to a Post-Quantum algorithm, we might need to upgrade the server hardware first (Risk Assessment)."

Why This Matters (The "Post-Quantum" Future)

The paper mentions Post-Quantum Cryptography. Imagine a future where a giant hammer (Quantum Computer) can smash all current locks.

If you only have a grocery list, you don't know which locks to replace first. You might replace the front door lock but leave the back gate open.

But with the SATAM Super-List, you know exactly:

Which locks are critical to the fortress's survival.
Which locks are easy to swap.
Which locks are so tied to the building's structure that swapping them requires rebuilding the wall.

Summary

The paper argues that we stop treating encryption like a grocery list and start treating it like architectural design.

By using SATAM, organizations can create a "Smart Inventory" that tells them not just what they have, but why they have it and how to change it safely. This makes it much easier to upgrade security without accidentally breaking the system or leaving the door wide open.

1. Problem Statement

Cryptographic systems face continuous pressure from algorithm deprecation, regulatory changes, and the impending transition to post-quantum cryptography (PQC). While Cryptographic Bills of Materials (CBOMs) exist to inventory cryptographic assets (algorithms, libraries, keys), current approaches suffer from critical limitations:

Inventory-First Approach: Existing CBOMs are typically generated via static analysis or tooling, resulting in a list of components without architectural context.
Lack of Rationale: They fail to capture why specific cryptography is used, the security intent behind it, or the tradeoffs considered during design.
Migration Blindness: Without architectural context, it is difficult to assess the security impact, feasibility, or risk of replacing a cryptographic mechanism. This leads to "black box" migrations that risk unintended security regressions.
Disconnected Artifacts: Threat models (e.g., STRIDE), architectural decisions (ADRs), and risk assessments (e.g., CARAF) are often maintained in isolation, lacking a unified traceability chain to the cryptographic inventory.

2. Methodology: SATAM

The authors propose SATAM (Security-Aware Architecture Tradeoff Analysis Method), a security-aware adaptation of the ATAM (Architecture Tradeoff Analysis Method). SATAM is designed to derive a CBOM directly from architectural analysis, enriching it with security intent and migration-critical metadata.

Core Process Flow

SATAM follows the high-level phases of ATAM but integrates specific security and cryptographic activities:

Preparation: Define security stakeholders and use arc42 (an architectural documentation template) as the baseline. The architecture is made "security-readable" by explicitly marking trust boundaries and cryptographic termination points.
Threat Modeling: Apply STRIDE to architectural elements (components, data flows, trust boundaries) to identify specific threats.
Scenario Definition: Transform STRIDE threats into Security Quality Attribute Scenarios (Security QAS). These define measurable system behaviors required to mitigate threats (e.g., "Reject modified traffic within 1 second").
Decision Documentation: Architectural responses to QAS (e.g., selecting TLS 1.3, specific key management) are documented as Architecture Decision Records (ADRs). These capture the rationale, context, and consequences of cryptographic choices.
Risk Assessment: Apply the Crypto Agility Risk Assessment Framework (CARAF) to the ADRs. CARAF evaluates migration risks based on data lifetime ( $X$ ), migration time ( $Y$ ), and the cryptographic horizon ( $Z$ ), specifically addressing "harvest now, decrypt later" threats.
CBOM Generation: The final CBOM is not a separate inventory but a machine-readable artifact (CycloneDX compatible) derived directly from the ADRs and architectural elements. Each entry is annotated with:
- The architectural element it protects.
- The STRIDE threats it mitigates.
- The Security QAS it satisfies.
- The ADR justifying its selection.
- CARAF findings regarding migration risk and agility.

Traceability Model

The method relies on a strict traceability chain:
Architectural Elements $\rightarrow$ STRIDE Threats $\rightarrow$ Security QAS $\rightarrow$ ADRs $\rightarrow$ CARAF Findings $\rightarrow$ Annotated CBOM.

3. Key Contributions

SATAM Method: A novel, structured method for integrating security-aware architecture evaluation with cryptographic inventorying. It treats security as a first-class quality attribute and makes cryptographic assumptions explicit early in the evaluation.
Architecture-Grounded CBOM: A shift from tool-derived inventories to architecture-derived CBOMs. These artifacts capture the "why" and "how" of cryptographic usage, not just the "what."
Unified Traceability Model: A conceptual model linking architectural elements, threats, decisions, and risk assessments, ensuring that every CBOM entry is traceable back to a security requirement and a design decision.
Integration of CARAF: Demonstrates how architecture-derived artifacts (ADRs, QAS) provide the necessary structured input for quantitative and qualitative risk assessment frameworks like CARAF, specifically for post-quantum readiness.
Proof-of-Concept: A demonstration on a system with an API Gateway, Backend Service, and Database, showing the flow from arc42 documentation to an annotated CBOM entry.

4. Results

The paper validates SATAM through a Design Science Research (DSR) approach, utilizing analytical evaluation and a proof-of-concept instantiation:

Contextual Enrichment: The generated CBOM entries included migration-critical metadata (e.g., certificate lifecycles, interoperability dependencies, and data lifetime constraints) that are absent in standard tool-generated CBOMs.
Risk Visibility: By linking CBOM entries to CARAF findings, the method successfully identified specific migration risks (e.g., high cost of migration due to certificate rotation constraints) and highlighted "harvest now, decrypt later" vulnerabilities.
Decision Support: The method provides stakeholders with the necessary context to make informed decisions about cryptographic replacements, balancing security requirements against operational constraints and migration costs.

5. Significance

Cryptographic Agility: SATAM directly addresses the need for long-term cryptographic agility. By documenting the rationale and constraints of current cryptographic choices, organizations can plan migrations more effectively without compromising system security.
Post-Quantum Readiness: The method is particularly relevant for the transition to Post-Quantum Cryptography (PQC). It provides a structured way to assess which assets are vulnerable to future quantum attacks and how difficult they are to migrate.
Bridging the Gap: It bridges the gap between high-level security architecture (threat modeling) and low-level compliance/inventory (CBOMs), solving the problem of "semantic ambiguity" in software bills of materials.
Standardization: The approach aligns with emerging standards like CycloneDX, suggesting a pathway for extending SBOM/CBOM standards to include architectural intent and security rationale.

In conclusion, SATAM transforms the CBOM from a static inventory into a dynamic, security-aware architectural artifact, enabling organizations to navigate the complex landscape of cryptographic migration with greater transparency, reduced risk, and improved strategic planning.