Building Secure Systems: A Blueprint for Cryptographic Upgrades

by

Author: Denis Avetisyan

Modern software relies heavily on cryptography, and keeping those systems secure requires a proactive, architecture-driven approach to managing and migrating cryptographic components.

This paper presents SATAM, a method for generating architecture-derived Cryptographic Bills of Materials (CBOMs) that links cryptographic choices to security rationale and facilitates efficient migration planning.

Effective cryptographic migration requires more than simply cataloging deployed algorithms. This paper introduces the Architecture-Derived CBOMs for Cryptographic Migration: A Security-Aware Architecture Tradeoff Method and presents SATAM, a novel approach for generating Cryptographic Bills of Materials (CBOMs) grounded in architectural decisions and security rationale. By integrating established techniques-including ATAM, arc42, and STRIDE-SATAM annotates CBOM entries with critical context, improving traceability and informed planning. Does this architecture-centric approach offer a pathway toward more agile and resilient cryptographic systems in the face of evolving threats and regulatory demands?

The Usual Suspects: Why Architecture Evaluations Fail Security

Traditional software architecture evaluations frequently prioritize functional requirements and performance, often treating security as an afterthought or a superficial checklist item. This approach results in a limited assessment of potential vulnerabilities, leading to their discovery much later in the development lifecycle-typically during penetration testing or, worse, after deployment. The consequences of this delayed detection are significant, requiring costly rework, potential data breaches, and reputational damage. Current methods struggle to proactively identify subtle security flaws embedded within the architectural design itself, focusing instead on implementation-level bugs. Consequently, critical security considerations-such as attack surface reduction, threat modeling integration, and the enforcement of security principles-are often overlooked until vulnerabilities are actively exploited, highlighting a systemic gap in how software architecture is evaluated for robust security.

Traditional software architecture evaluations often treat cryptography as a simple component, failing to deeply analyze its implications for long-term security and adaptability. These evaluations typically lack the necessary granularity to assess how specific cryptographic algorithms, key lengths, and protocols will withstand future attacks or accommodate evolving standards – such as the anticipated challenges posed by quantum computing. A superficial review might confirm adherence to current best practices, but doesn’t account for the agility required to migrate to more secure alternatives when vulnerabilities are discovered or algorithms become obsolete. Consequently, systems can become locked into fragile cryptographic foundations, demanding costly and disruptive refactoring efforts later in their lifecycle, or worse, remaining vulnerable to increasingly sophisticated threats.

Effective risk management relies heavily on a clear understanding of how architectural choices translate into security postures, yet many organizations struggle with a demonstrable link between these elements. Without formal traceability – a documented path from initial architectural designs, through defined security requirements, and finally to concrete implementation details – vulnerabilities can easily emerge from misinterpretations or overlooked dependencies. This lack of connection creates a significant blind spot, making it difficult to assess the true impact of potential threats and to confidently validate the effectiveness of implemented security controls. Consequently, identifying and mitigating risks becomes a reactive, rather than proactive, process, increasing the likelihood of costly rework and potential security breaches. A robust system of traceability, therefore, isn’t merely a best practice, but a critical component of a resilient and secure software architecture.

Organizations face considerable challenges in maintaining secure systems due to the dynamic nature of modern threats and cryptographic standards. Without a formalized and continuous architecture evaluation process, adapting to these changes becomes reactive rather than proactive. This often results in technical debt, where cryptographic algorithms become obsolete or vulnerable, and architectural decisions lack the flexibility to accommodate new security protocols. The inability to systematically assess and address these evolving risks leaves organizations susceptible to breaches and compliance failures, hindering their ability to confidently innovate and deploy secure software. A robust evaluation process isn’t merely a point-in-time assessment, but an ongoing lifecycle activity ensuring architectural resilience and long-term security posture.

SATAM: Adding a Little Sanity to Security Evaluations

SATAM (Security-Aware Threat Analysis Method) builds upon established architectural evaluation techniques, notably the Architecture Tradeoff Analysis Method (ATAM), by explicitly incorporating security and cryptographic agility as primary concerns. Unlike traditional ATAM implementations which treat security as one attribute among many, SATAM centers the evaluation process on identifying and mitigating security risks inherent in the system architecture. This is achieved through a dedicated focus on cryptographic choices, key management practices, and the potential impact of cryptographic algorithm obsolescence or compromise. SATAM does not replace existing architectural reviews but rather augments them with specialized security-focused analyses, allowing for the proactive identification of vulnerabilities before implementation and enabling the design of systems capable of adapting to evolving cryptographic standards and threats.

SATAM employs scenario-based analysis as a core component of its evaluation process, focusing on proactive identification of security vulnerabilities during the architectural design phase. This involves constructing realistic usage scenarios that detail interactions between system components and external actors, allowing analysts to systematically explore potential attack surfaces. By analyzing these scenarios, SATAM aims to uncover vulnerabilities before implementation, reducing the cost and complexity of remediation. The method emphasizes the creation of detailed narratives describing system behavior under both normal and adversarial conditions, facilitating a thorough assessment of security risks and informing architectural decisions to mitigate them. This early-stage analysis allows for iterative refinement of the architecture to incorporate security considerations from the outset.

SATAM employs STRIDE – Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege – as a foundational threat modeling technique to systematically identify potential security risks within the system architecture. This process involves analyzing the system components and data flows to determine how each STRIDE category could be exploited. Complementing STRIDE, Security Quality Attribute Scenarios (QAS) are utilized to articulate specific security requirements as testable scenarios. These QAS define acceptable system behavior under various security-related conditions, focusing on how the system should respond to threats and maintain its security posture; each scenario details a stimulus, an expected response, and any relevant environmental conditions, providing a concrete basis for security validation and verification throughout the development lifecycle.

SATAM is designed to integrate with established architectural documentation frameworks, specifically arc42, to minimize disruption to existing development workflows. This integration facilitates a seamless evaluation process by leveraging pre-existing architectural descriptions, views, and decisions captured within arc42 documentation. Rather than requiring entirely new documentation, SATAM utilizes arc42 as a source of truth, extracting relevant information for security analysis. This approach reduces the overhead associated with security evaluations and allows security concerns to be addressed within the context of the overall system architecture, ensuring consistency and traceability between architectural design and security posture.

Traceability: Finally, a Paper Trail for Security Decisions

The SATAM traceability model functions by defining explicit relationships between four core components: architectural elements, security concerns, cryptographic decisions, and supporting documentation. This is achieved through a structured approach where each architectural element is linked to specific security concerns it addresses. Subsequently, cryptographic decisions made to fulfill those security concerns are recorded, along with references to relevant documentation such as Architectural Decision Records (ADRs) or design specifications. This interconnectedness allows for comprehensive tracking of security rationale throughout the system’s lifecycle, enabling verification of implementation against stated security requirements and facilitating impact analysis of potential changes.

The SATAM traceability model maintains a comprehensive record of all security-relevant architectural decisions, cryptographic choices, and associated rationale. This explicit recording enables detailed auditing of the security posture, providing a verifiable chain of evidence linking requirements to implementation. Each decision, including the justification for selecting specific algorithms or protocols, is documented and cross-referenced with relevant architectural elements. This detailed log facilitates impact analysis when vulnerabilities are discovered or new threats emerge, allowing security teams to quickly identify affected components and prioritize remediation efforts. The auditable nature of the model also supports compliance with regulatory requirements and industry standards that mandate demonstrable security practices.

SATAM enhances cryptographic agility by explicitly associating cryptographic choices with Architectural Decision Records (ADRs), creating an auditable rationale for each selection. This linkage is critical for long-term maintenance, as it allows for informed reassessment of cryptographic algorithms and protocols when vulnerabilities are discovered or standards evolve. A key outcome of this process is the automated derivation of architecture-grounded Cryptographic Bills of Materials (CBOMs), which detail all cryptographic components used within the system and their associated metadata. These CBOMs facilitate proactive cryptographic migration planning by identifying potential obsolescence risks and enabling efficient updates or replacements, minimizing disruption and ensuring continued security compliance.

Security Quality Attributes (SQAs) within the SATAM framework are directly derived from the results of Threat Modeling exercises, ensuring evaluation scenarios are grounded in realistic, identified threats. This process moves beyond generic security testing by focusing evaluations on vulnerabilities and attack vectors specific to the system’s architecture and operational context. Threat Modeling identifies potential weaknesses, which are then translated into measurable SQAs – such as confidentiality, integrity, or availability – and used to define specific test cases. The resulting evaluations, therefore, accurately reflect the likelihood and impact of real-world security threats as opposed to hypothetical or broadly applicable vulnerabilities, increasing the effectiveness of security validation efforts.

The pursuit of elegantly scalable systems, as detailed in this architecture-driven approach to Cryptographic Bill of Materials, often feels like building castles on shifting sand. It’s a sentiment Grace Hopper captured perfectly when she said, “It’s easier to ask forgiveness than it is to get permission.” This paper’s focus on linking cryptographic choices directly to architectural context – creating traceability – isn’t about preventing breakage, it’s about understanding where things will inevitably fail. Because, as any seasoned architect knows, production will always find the edge cases the models missed. SATAM doesn’t promise a flawless migration, only a more informed autopsy when the inevitable happens.

What’s Next?

The promise of architecture-derived CBOMs, as articulated by this work, feels…familiar. Another layer of abstraction built upon the shifting sands of ‘security rationale.’ It’s a good idea, certainly, and one suspects future teams will be grateful for some record of why those particular cryptographic choices were made. Though, one also anticipates a frantic search for the architect who understood the original threat model, because documentation, inevitably, lied again. The real challenge isn’t creating the CBOM; it’s maintaining it when the system, inevitably, morphs from a simple bash script into a distributed, microservice-based behemoth.

Future work will undoubtedly focus on automation – attempting to derive these CBOMs directly from architectural models. They’ll call it AI and raise funding. But the devil, predictably, will be in the edge cases: the bespoke algorithms, the undocumented dependencies, the ‘security through obscurity’ that always seems to creep in. A more fruitful avenue might be exploring how these architecture-grounded CBOMs interact with, or perhaps constrain, the design process itself – forcing architects to explicitly consider cryptographic implications from the outset, rather than bolting them on as an afterthought.

Ultimately, this isn’t about better tooling; it’s about acknowledging that tech debt is just emotional debt with commits. A beautifully crafted CBOM won’t magically solve the underlying problem of systemic architectural erosion. It will, however, provide a slightly more detailed autopsy when the inevitable breach occurs. And that, in this field, is progress of a sort.

Original article: https://arxiv.org/pdf/2603.22442.pdf

Contact the author: https://www.linkedin.com/in/avetisyan/

See also:

2026-03-25 16:58