Attributes in the Codex
Attributes in the Devici Codex define how system behavior and data characteristics are interpreted during threat modeling.
They are the foundational input that drives threat generation. When attributes are added to elements in a threat model, the Codex evaluates those attributes, determines which threats apply, and surfaces the corresponding mitigations.
Use this page to understand how Codex attributes are designed, how they map to threats, and how to create and manage them responsibly.
Role of attributes in threat modeling
Threat modeling in Devici follows a clear and consistent relationship:
Attributes → Threats → Mitigations
- Attributes describe behavior or data characteristics
- Threats represent risks that apply when those attributes are present
- Mitigations describe controls that reduce or manage those risks
Attributes are added to elements during threat modeling.
The Codex defines how those attributes map to threats and mitigations.
Attributes do not represent controls or decisions.
They represent conditions and assumptions.
Types of Codex attributes
The Codex includes two primary categories of attributes.
Functional attributes
Functional attributes describe what an element does, such as: - Accepting unauthenticated input - Executing code - Enforcing authorization - Trusting upstream systems
These attributes help the Codex reason about behavior and exposure.
Data attributes
Data attributes describe what kind of data an element processes, stores, or transmits.
Examples include: - Credentials - Personal data - Financial data - Secrets or tokens - Logs or telemetry
Data attributes help the Codex understand what is at risk if a threat is realized.
Creating Codex attributes
When built-in attributes are insufficient, you can create custom Codex attributes to extend Devici’s threat intelligence.
When to create a custom attribute
Create a custom attribute when: - The behavior or data characteristic is stable and reusable - The attribute represents a meaningful security condition - No built-in attribute reasonably captures the behavior
Avoid creating custom attributes for: - One-off implementations - Temporary design decisions - Controls or mitigations
At a high level, creating a Codex attribute involves:
- Defining the behavior or data characteristic the attribute represents
- Ensuring the attribute is technology-agnostic and reusable
- Making the attribute available for selection during threat modeling
- Mapping the attribute to one or more threats
Custom attributes become part of the Codex and can be reused across threat models.
Tip
Good Codex attributes describe conditions, not solutions. If it sounds like a control, it probably belongs as a mitigation.
Mapping attributes to threats
Attributes drive threat generation through explicit mappings in the Codex.
How attribute-to-threat mapping works
When an attribute is mapped to a threat: - The threat becomes eligible whenever that attribute is applied to an element - Context (other attributes, data flows, trust boundaries) further refines applicability - The Codex explains why the threat applies based on the mapping
A single attribute may map to: - Multiple threats, or - Different threats depending on context
Likewise, a single threat may be associated with: - Multiple attributes
Designing effective mappings
When mapping attributes to threats:
- Ensure the threat genuinely depends on the attribute being present
- Avoid overly broad mappings that generate noise
- Prefer fewer, higher-quality mappings over exhaustive coverage
Warning
Over-mapping attributes to threats is one of the most common sources of noisy threat models. Every mapping should be intentional and defensible.
Attribute combinations and context
Threat generation is not based on attributes in isolation.
The Codex evaluates: - Multiple attributes on the same element - Interactions through data flows - Trust boundary crossings
This allows Devici to: - Surface higher-risk conditions - Suppress irrelevant threats - Explain threat applicability clearly
If a threat appears surprising, it is often the combination of attributes—not a single attribute—that triggered it.
Built-in vs custom attributes
Built-in Codex attributes
Built-in attributes are maintained by Devici and: - Reflect common security-relevant behaviors - Map to curated threats and mitigations - Ensure consistency across teams and models
Built-in attributes cannot be modified by users.
Custom Codex attributes
Custom attributes allow organizations to model: - Internal platform assumptions - Domain-specific behavior - Organization-specific risk patterns
Custom attributes: - Coexist with built-in attributes - Map to custom or built-in threats - Do not override built-in Codex logic
Governance and best practices
Because Codex attributes influence threat generation across all models, they should be governed carefully.
Recommended governance practices
- Limit who can create or modify Codex content
- Review new attributes before broad adoption
- Prefer shared, reusable attributes over many similar variants
- Periodically review attribute usage and mappings
Warning
Uncontrolled Codex changes can fragment threat modeling outcomes and reduce consistency across teams.
Common misconceptions about Codex attributes
Avoid these misunderstandings:
- Attributes are not mitigations
- Attributes do not represent implemented controls
- More attributes does not automatically mean better coverage
- Codex attributes define intelligence, not risk acceptance
Attributes describe conditions, not decisions.
What’s next
To continue exploring Codex concepts, see:
To learn how to apply attributes during threat modeling, see
Attributes are the foundation of threat intelligence in Devici.