Architecture
Which services need trust relationships, and can a safer workload identity reduce long-lived secret use?
High School AdvancedA11.4Secure Software Architecture
Lesson A11.4
Secrets Management Concepts
Software often depends on sensitive credentials, keys, tokens, and configuration to authenticate services and protect important operations. Secure architecture must govern those secrets across their entire lifecycle — without exposing the values themselves.
This lesson uses metadata-only fictional records. You will work with ownership, purpose, scope, environment, storage class, rotation, status, dependencies, and retirement evidence. No real passwords, tokens, keys, cookies, or credentials are used or requested.
Lesson Progress
Secrets Management Concepts
High School Advanced • A11: Secure Software Architecture • Lesson 4 of 10
40% complete
Readiness Check
A11.4 Entry Readiness
0/4 ready
Professional Hook
A Secret Is More Than a Value
Imagine a fictional application needs a credential to connect to a reporting database. The team may know the credential exists, but secure architecture needs many more answers.
Who owns it? Which service is allowed to use it? Which environment does it belong to? What permissions does it carry? Where is it stored? When is it rotated? Which services depend on it? How would the team know rotation failed? What happens when the reporting job is retired?
The value is secret. The governance should be visible.
Learning Objectives
Five Capabilities for This Lesson
1
Explain why secrets management is a lifecycle and governance problem rather than simply a storage problem.
2
Distinguish secret values from metadata such as owner, purpose, environment, access scope, rotation date, expiration, and status.
3
Evaluate fictional secret records for ownership, environment separation, least privilege, rotation, redaction, monitoring, and retirement readiness.
4
Recognize common design weaknesses such as embedded secrets, shared secrets, stale credentials, overbroad access, weak ownership, missing rotation, and unsafe logging.
5
Build a metadata-only secrets governance model that connects A11 requirements, threat modeling, review, testing, deployment, and maintenance.
Why It Matters
Secrets Connect Architecture, Identity, Deployment, and Operations
Secrets are often treated as a small implementation detail, but their lifecycle touches architecture, identity, configuration, dependencies, deployment, logging, monitoring, incident response, and retirement.
Deployment
How does the approved workload receive access without copying secret values into code or ordinary configuration?
Operations
Who owns rotation, monitoring, exceptions, revocation, and retirement after release?
Core Framework
Eight Stages of the Secret Lifecycle
A secret should have a beginning, controlled use, review points, and a clear end. A lifecycle model helps prevent forgotten credentials, uncontrolled copies, unclear ownership, and indefinite access.
01
Create
Why does this secret exist and what system or workflow needs it?
Define business purpose, secret type, owner, environment, approved system, initial scope, expiration expectation, and whether a less-sensitive design could avoid the secret entirely.
Evidence: Secret metadata record, design requirement, architecture decision, approval note.
02
Store
Where should the secret be kept?
Use approved managed storage or platform mechanisms rather than source code, shared documents, chat messages, tickets, or unprotected configuration.
Evidence: Storage policy, metadata reference, configuration design, repository review evidence.
03
Distribute
How does the approved workload receive access?
Limit delivery to the intended service, environment, identity, and workflow. Avoid unnecessary copying or human exposure.
Evidence: Access policy summary, workload identity record, environment mapping, approval record.
04
Use
What is the minimum access necessary for the secret's purpose?
Apply least privilege, environment separation, purpose limitation, and appropriate service identities. Do not expose values in logs, errors, dashboards, or user interfaces.
Evidence: Permission metadata, service-owner record, logging design, validation evidence.
05
Monitor
How would the team know if governance or access changed?
Monitor ownership, access-policy changes, failed access, stale rotation, expiration, source health, configuration drift, and unauthorized copying indicators at a policy level.
Evidence: Dashboard status, audit summaries, source-health metrics, exception register.
06
Rotate
How is the secret replaced safely without breaking the service?
Define rotation owner, schedule, compatibility window, dependent services, validation steps, rollback, and evidence that the old secret was retired.
Evidence: Rotation record, dependency map, validation result, rollback plan, retirement evidence.
07
Revoke
When must access be removed immediately?
Revoke when purpose ends, ownership changes, a service is retired, access is no longer needed, or governance evidence indicates the secret should no longer be trusted.
Evidence: Revocation approval, access-removal record, service validation, follow-up review.
08
Retire
How do we prove the secret is no longer active or needed?
Confirm old values are no longer referenced, dependent workflows use approved replacements, permissions are removed, and the metadata record is closed.
Evidence: Retirement status, dependency confirmation, owner sign-off, post-change validation.
Secret Categories
What Software Teams Commonly Govern
The exact technology can differ, but the governance questions remain similar. In this lesson, we only discuss categories and metadata.
Service credential
Allows an approved service or workload to authenticate to another approved system.
Governance: Owner, system identity, environment, destination, access scope, rotation, retirement.
API token
Represents approved access to an API or external service.
Governance: Purpose, owner, allowed service, environment, scope, expiration, rotation, supplier dependency.
Encryption key reference
Supports approved protection or cryptographic operations.
Governance: Key owner, purpose, environment, rotation or lifecycle, service dependency, recovery policy.
Signing key reference
Supports approved integrity or authenticity operations.
Governance: Owner, signing purpose, protected use, rotation, revocation, audit, retirement.
Database credential
Allows an application or approved service identity to connect to a data service.
Governance: Application owner, database scope, environment, permissions, storage, rotation, monitoring.
Webhook secret reference
Supports validation of approved webhook interactions.
Governance: Integration owner, environment, supplier, rotation, logging boundary, retirement trigger.
Vocabulary
Secrets Management Terms
Secret
A sensitive value used to authenticate, authorize, encrypt, sign, or otherwise protect a system interaction.
Secret metadata
Non-secret information about a secret, such as owner, purpose, environment, type, scope, rotation date, status, and dependencies.
Secret store
An approved managed system or platform mechanism designed to protect and control access to secret values.
Least privilege
Limiting secret access and permissions to the minimum needed for the intended service and purpose.
Environment separation
Keeping development, test, staging, and production secret access appropriately separated.
Rotation
Replacing a secret with a new approved value according to policy or risk conditions while safely updating dependencies.
Revocation
Ending the validity or access of a secret when it should no longer be trusted or used.
Expiration
A defined point after which a secret should no longer be accepted without renewal or replacement.
Redaction
Preventing sensitive secret values from appearing in logs, errors, dashboards, reports, or user-visible output.
Secret sprawl
The uncontrolled copying or spread of secrets across repositories, files, systems, people, or environments.
Workload identity
An identity assigned to a service or workload so it can authenticate without unnecessary shared human credentials.
Break-glass access
A tightly governed emergency access path with explicit approval, monitoring, review, and limited use.
Design Principles
Six Principles for Safer Secret Architecture
Avoid secrets when possible
If an approved workload identity or platform-native trust mechanism can meet the need without a long-lived secret, reducing secret count can reduce lifecycle burden.
Store values in approved systems
Source code, shared documents, tickets, chat messages, screenshots, and ordinary configuration files are poor places for secret values.
Separate environments
Development, test, staging, and production should not casually share the same secret values or access patterns.
Limit access and scope
A secret should only reach the service, identity, environment, and resource needed for its purpose.
Rotate and retire
Secrets should have a lifecycle. Teams need owners, review triggers, rotation procedures, validation, rollback, and evidence that old access is closed.
Keep values out of evidence
Security reviews should usually rely on metadata, status, policy, ownership, and validation evidence rather than exposing actual secret values.
Fake Dashboard
Northbridge Secrets Governance Dashboard
Fictional metadata only — no secret values
Tracked secret records
38
Metadata-only inventory; no values displayed
Owned records
36 / 38
Two production records need ownership remediation
Rotation compliance
92%
Three records are overdue or lack current review dates
Environment separation
97%
One legacy shared credential spans two services
Fake SOC Alert
Unowned Production Secret Record
Source: Fictional Secrets Governance Review • Time: 09:22
SEC-03 is a production database credential record with approved storage and read-only scope, but the owner and current rotation review are missing.
Defensive recommendation: Keep status Unknown, assign an accountable owner, define the rotation schedule, and collect governance evidence before release approval.
Fictional Secret Register
Metadata-Only Review
A security reviewer usually does not need to see the actual secret value. The register below shows how purpose, ownership, environment, storage, scope, rotation, and status can support governance review.
SEC-01Service credentialConfirmed
Purpose
Application service to internal record API
Owner
Application Platform Owner
Environment
Production
Storage
Approved managed secret store
Scope
Record API service identity only
Rotation
Every 90 days or on approved risk trigger
Concern
None in supplied metadata
Next action
Continue source-health and rotation review.
SEC-02API tokenConditional
Purpose
Scheduling integration
Owner
Integration Owner
Environment
Production
Storage
Approved managed secret store
Scope
Scheduling API minimum approved operations
Rotation
Every 60 days
Concern
Supplier dependency change planned next quarter
Next action
Re-review scope and rotation before supplier migration.
SEC-03Database credentialUnknown
Purpose
Reporting job to reporting database
Owner
Unknown
Environment
Production
Storage
Approved store listed
Scope
Read-only reporting role
Rotation
No current owner or review date
Concern
Ownership and rotation governance incomplete
Next action
Assign owner and rotation schedule before Confirmed status.
SEC-04Webhook secret referenceConfirmed
Purpose
Notification provider callbacks
Owner
Notification Service Owner
Environment
Staging
Storage
Approved managed secret store
Scope
Staging notification callback only
Rotation
Every 90 days
Concern
No production sharing allowed
Next action
Keep staging and production metadata separate.
SEC-05Signing key referenceConfirmed
Purpose
Approved release artifact signing
Owner
Release Engineering Owner
Environment
Build / Release
Storage
Protected signing service
Scope
Approved release pipeline only
Rotation
Policy-based lifecycle
Concern
Emergency access path requires quarterly review
Next action
Review emergency access evidence and approval logs.
SEC-06Legacy shared credentialBlocked
Purpose
Old maintenance integration
Owner
Legacy Service Owner
Environment
Production
Storage
Migration pending
Scope
Two legacy services
Rotation
Manual and overdue
Concern
Shared access and overdue migration increase lifecycle risk
Next action
Replace with separate approved service identities and retire shared credential.
Fake Log Panel
Fictional Secret Governance Log
training-log-viewer.log
[08:40] SEC-01 owner=Application Platform status=CONFIRMED rotation=current [09:05] SEC-02 supplier-change trigger opened for scheduling integration [09:22] SEC-03 owner=UNKNOWN rotation-review=missing [09:45] SEC-04 staging-only scope confirmed; production sharing=NOT ALLOWED [10:10] SEC-05 emergency-access review due this quarter [10:31] SEC-06 shared credential rotation overdue -> status=BLOCKED [11:02] REDACTION review confirms secret values absent from approved audit examples
Training note: this is fake data for defensive analysis practice only.
Review Questions
Fourteen Questions for Every Secret Record
1
What business purpose requires this secret?
2
Could a safer identity or platform mechanism remove the need for a long-lived secret?
3
Who owns the secret metadata and lifecycle?
4
Which workload or person is allowed to use it?
5
Which environment does it belong to?
6
What is the minimum permission or scope needed?
7
Where is the value stored?
8
How is access delivered without unnecessary copying?
9
What is the rotation or expiration expectation?
10
What dependencies must be updated during rotation?
11
What evidence proves the old secret is retired?
12
How are policy changes and stale rotation monitored?
13
Which logs or dashboards must never reveal the secret value?
14
What future changes should trigger re-review?
Analyze the Evidence
Evidence Analysis: Unowned Credential
The record is for a production reporting database credential.
Approved managed storage is listed.
Read-only scope is documented.
Owner is Unknown.
No current rotation review date is recorded.
What is the strongest conclusion about SEC-03?
Environment Separation
Development, Test, and Production Should Not Blur Together
Different environments have different users, data, controls, and failure expectations. Sharing the same secret across environments can make a lower-trust environment part of the production trust model.
| Question | Weak pattern | Stronger pattern |
|---|---|---|
| Values | One shared credential for test and production | Environment-specific secret records and access |
| Ownership | Everyone on the team can use the production secret | Only approved workload identities and accountable owners have access |
| Storage | Local files or copied environment variables in documentation | Approved environment-specific managed storage |
| Monitoring | No distinction between environments | Environment-aware governance, access, and source-health monitoring |
| Retirement | Test credentials remain active indefinitely | Unused environment credentials are revoked and closed |
Rotation
Rotation Is a Change Process, Not a Button
Replacing a secret can affect every service that depends on it. Strong teams understand dependencies, plan compatibility, validate the replacement, monitor the change, preserve rollback where appropriate, and confirm old access is retired.
1
Identify the secret owner and dependent services.
2
Confirm the new secret or identity path is approved.
3
Update the intended consumers only.
4
Validate expected service behavior.
5
Monitor errors and source health during the change.
6
Keep rollback bounded and time-limited.
7
Revoke or retire the old secret after successful validation.
8
Update the metadata record and close the rotation evidence.
Redaction
Logs Need Evidence — Not Secret Values
Logs should help defenders understand who or what requested access, which secret record or service was involved, whether access succeeded, when the event happened, and which policy applied.
Useful metadata
Secret record ID, service identity, environment, operation type, result, timestamp, policy decision, correlation identifier.
Values to avoid
Secret value, token contents, passwords, private keys, session cookies, recovery codes, or unnecessary sensitive payloads.
Access monitoring
Unexpected identity use, denied access, policy changes, stale rotation, exception use, or unusual ownership changes.
Source health
Whether the audit source is delivering current events, parsing correctly, and meeting retention expectations.
Common Mistakes
Eight Ways Secret Governance Breaks Down
1
Putting secrets in source code
Why it fails: Repositories are designed for sharing and history, which can spread sensitive values far beyond the intended workload.
Better approach: Keep values in approved managed storage and reference them through approved runtime mechanisms.
2
Sharing one secret across environments
Why it fails: A lower-trust environment can become linked to production access and make ownership or incident scope harder to understand.
Better approach: Use environment-specific access and governance.
3
Long-lived secrets with no review
Why it fails: Access can remain active after business purpose, ownership, or dependency conditions change.
Better approach: Define rotation, expiration, review triggers, and retirement evidence.
4
No owner
Why it fails: Nobody is accountable for rotation, scope, incident response, or retirement.
Better approach: Assign a named role or team and an escalation path.
5
Logging secret values
Why it fails: Logs often have broader access and longer retention than the secret was intended to have.
Better approach: Log metadata and status, not secret values.
6
Copying secrets for convenience
Why it fails: Each copy creates another location to govern, rotate, revoke, and audit.
Better approach: Prefer centralized managed access and workload identity where appropriate.
7
Rotating without dependency planning
Why it fails: A secret change can break services when consumers, compatibility windows, and rollback are not understood.
Better approach: Map dependencies, validate the new path, retire the old value, and preserve rollback where appropriate.
8
Retiring a service but leaving credentials active
Why it fails: Unused credentials can survive the system they once supported.
Better approach: Treat secret revocation and retirement as required end-of-life evidence.
Scenario Decision Lab
Scenario Decision Lab 1 — Missing Owner
A production database credential is stored in an approved secret system and has read-only scope. During release review, the team discovers that no owner or current rotation review is recorded.
Scenario Decision Lab
Scenario Decision Lab 2 — Legacy Shared Credential Rotation
Two legacy services still use the same fictional shared credential. The team plans to replace it as part of a migration, but several dependent workflows have not yet been documented.
Safe Fictional Lab
Build a Metadata-Only Secret Governance Register
Use only fictional records. Do not enter any real password, token, key, cookie, credential, hostname, internal route, or production configuration.
1
Create at least eight fictional secret records.
2
Give each record a stable ID.
3
Record type and business purpose.
4
Assign an owner.
5
Record environment and approved storage class.
6
Define the minimum service or workload scope.
7
Define rotation or expiration expectations.
8
List dependent fictional services.
9
Record monitoring and redaction expectations.
10
Assign status: Confirmed, Conditional, Unknown, Blocked, or Retired.
11
Add a next action for non-Confirmed records.
12
Define change triggers and retirement conditions.
Analyze the Evidence
Evidence Analysis: Legacy Shared Credential
SEC-06 is shared by two legacy services.
Rotation is overdue.
The migration plan intends to replace shared access with separate service identities.
Some dependent workflows are not yet documented.
The current status is Blocked.
What is the strongest architectural response to SEC-06?
Advanced Challenge
Design a Secretless-or-Minimized Trust Pattern
Review a fictional internal service-to-service workflow and ask whether a long-lived shared secret is necessary at all.
1
Which workload needs to authenticate?
2
Which service is the destination?
3
What business purpose requires the trust relationship?
4
Can an approved workload identity or platform-native mechanism reduce secret use?
5
Which environment is in scope?
6
What is the minimum permission needed?
7
Who owns the trust relationship?
8
What evidence validates the identity path?
9
What logging should exist without exposing values?
10
What happens when the workload is retired?
11
What change triggers reopen the design?
12
What residual risk remains?
The challenge is not to eliminate every secret. It is to minimize unnecessary long-lived secrets and make every remaining trust relationship governable.
Defender Habits
A11.4 Defender Checklist
Skill Check
Seven Questions
Check Your Understanding
A11.4 Mini Quiz: Secrets Management Concepts
Choose your answers first. Explanations appear only after submission.
1. What is the strongest description of secrets management?
2. Why should security reviews use secret metadata instead of secret values whenever possible?
3. Which situation is the strongest example of environment-separation risk?
4. A production database credential has no owner or rotation date. What is the strongest status?
5. Why should secret values be excluded from logs?
6. What is an important part of safe secret rotation?
7. A service is permanently retired. What should happen to its secrets?
Portfolio Prompt
Portfolio Build — Secrets Governance Model
Create the fourth artifact for your A11 Secure Software Design Assessment: a metadata-only secrets governance model for a fictional application. Include at least eight secret records with ID, type, purpose, owner, environment, storage class, scope, rotation or expiration, dependencies, monitoring, status, next action, change trigger, and retirement condition. Do not include any secret values.
Use fictional metadata only.
Include at least one Unknown record with missing ownership.
Include at least one Blocked legacy shared-credential record.
Include one environment-separation example.
Include one rotation workflow with dependencies, validation, rollback, and retirement.
Explain how the design minimizes secret sprawl and protects logs from secret values.
Confidence / Readiness Reflection
Are You Ready for A11.5?
A11.5 moves from secret governance to dependency and software supply chain risk. Before continuing, make sure you can review secrets without ever needing to reveal the actual values.
1
I can distinguish a secret value from secret metadata.
2
I can explain why ownership, environment, scope, rotation, monitoring, and retirement are part of secret security.
3
I can identify secret-sprawl and shared-credential risks conceptually.
4
I can plan a rotation using dependency, validation, rollback, and retirement evidence.
5
I can keep secret values out of logs, reports, dashboards, labs, and portfolio artifacts.
Portfolio Build Guide
How to Make the Secrets Model Look Professional
Use metadata only
Never include real values. Show ID, purpose, owner, environment, scope, lifecycle, and status.
Show environment separation
Make clear which records belong to development, staging, production, build, or integration workflows.
Show ownership
Every record should have an accountable owner or remain visibly Unknown.
Show rotation dependencies
Document the fictional services that must be updated or validated during rotation.
Show redaction rules
Explain which metadata may appear in logs and which secret values must never appear.
Show exceptions
If a legacy shared secret remains, make the exception time-bounded, owned, monitored, and tied to migration.
Show retirement
Record how service shutdown, supplier change, or architecture replacement closes the secret lifecycle.
Connect to earlier A11 work
Link secret records to requirements and threat-model concerns from A11.2 and A11.3.
Key Takeaways
What You Should Remember
1.Secrets management is a lifecycle discipline covering creation, storage, distribution, use, monitoring, rotation, revocation, and retirement.
2.Metadata can support strong governance review without exposing secret values.
3.Ownership and purpose are foundational; an unowned secret is difficult to rotate, revoke, or retire safely.
4.Environment separation and least privilege reduce the scope of a secret's impact.
5.Rotation requires dependency planning, validation, rollback, and proof that old access is closed.
6.Logs, errors, dashboards, and portfolio artifacts should never expose secret values.
7.Shared and long-lived credentials increase lifecycle complexity and should be replaced where safer identity patterns are available.
8.Secret retirement must be part of software and service retirement.
9.A strong secrets governance model connects requirements, threat modeling, code review, deployment, monitoring, and maintenance.
Lesson Safety Boundary
Never use real secret values in CyberShield labs
This lesson does not request or authorize access to real passwords, tokens, keys, cookies, recovery codes, credentials, repositories, applications, APIs, devices, or networks. Use metadata-only fictional records and approved design evidence.
Lesson Complete
A11.4 Secrets Management Concepts Complete
You now have a metadata-first secrets governance model covering ownership, scope, storage, environment separation, redaction, rotation, revocation, monitoring, and retirement. Next, A11.5 expands software risk to Dependency and Supply Chain Risk Concepts.