Secure Software Development / Basic: outcomes, models, and decisions / Lesson 2

Map assets, data flows, and trust boundaries

Build a small model that explains where authority and sensitive data change hands.

About 4 min readContent reviewed 2026-10-28

On this page

Lesson goals

Identify assets, actors, stores, processes, and external dependencies.
Explain why a drawn boundary needs an associated trust decision.

Model what needs protection

An asset is something whose loss, disclosure, corruption, or misuse matters to the product. In the workshop service, attendee contact details, registration ownership, organizer permissions, and the integrity of attendance counts all deserve attention. Source code and build artifacts are also assets in the development process. Classify the data by meaning and required handling instead of assuming every field has equal sensitivity. A public workshop title and a private attendee email can travel through the same response object while requiring different disclosure rules. This distinction drives later projection and logging decisions.

Describe a flow with source, destination, and purpose

A useful data-flow model names the actor, process, store, data category, and direction. Avoid diagrams that show only boxes connected by unlabeled arrows. For an export, record where the organizer identity is established, where assigned workshops are loaded, which fields are selected, and where the result is delivered. Include background jobs and telemetry because they can move data beyond the visible request. The example is a non-runnable inventory of synthetic flows. It configures no service and does not claim those boundaries are implemented correctly.

json A labeled fictional export flow

{"model":"workshop-export-lab","flows":[{"from":"organizer-ui","to":"export-handler","data":"requested-workshop-id","trust":"untrusted-claim"},{"from":"identity-boundary","to":"export-handler","data":"validated-subject","trust":"reviewed-integration"},{"from":"registration-store","to":"export-handler","data":"attendee-contacts","trust":"scope-required"},{"from":"export-handler","to":"organizer-ui","data":"permitted-projection","trust":"authorization-required"}]}

The record separates a client claim from a trusted subject and scoped stored data. It is planning data rather than a deployed architecture. Actual middleware, storage predicates, and delivery controls require their own verification.

Attach a trust decision to every boundary

A trust boundary marks a change in assumptions or authority, not merely a network hop. Data read from storage can still be untrusted for an HTML or command context, and a familiar internal service can return a value outside the caller’s contract. Ask who controls the value and which property has actually been verified. The local program classifies client and reviewed identity facts differently. It does not implement identity validation; it demonstrates why copying a client-supplied organizer field cannot establish trusted context. Avoid treating the word internal as a substitute for evidence.

python Distinguish declared claim sources locally

facts = [{"name":"organizer","source":"client"}, {"name":"subject","source":"reviewed-identity-boundary"}]
def trusted_for_identity(fact):
    return fact["source"] == "reviewed-identity-boundary"
assert trusted_for_identity(facts[0]) is False
assert trusted_for_identity(facts[1]) is True
print("identity claim sources distinguished")

Expected output

identity claim sources distinguished

The complete program evaluates fictional provenance labels supplied by the exercise. A real caller must not be allowed to set its own trusted source label. No token, session, identity provider, or network connection is involved.

Record assumptions that could invalidate the model

A model is useful when its assumptions are explicit enough to challenge. State whether organizers can share workshops, whether exports are stored or streamed, whether jobs retain the requesting subject, and whether contact data enters logs. A change from synchronous delivery to a background download creates new lifetime and authorization questions. Keep unknowns visible rather than inventing reassuring defaults. Use a model revision tied to the feature change so a reviewer can see which boundary changed. Excessive diagram detail can obscure the one authority transition that matters most.

Use the map to select concrete reviews

Turn each important flow into a question with an owner and evidence source. For the client-to-handler flow, review parsing and domain validation; for identity-to-handler, review trusted context establishment; for store-to-export, review scope and field projection; for export-to-download, review access and expiry. A map without these follow-up questions becomes decoration. Conversely, a local parser or predicate cannot validate every arrow. Preserve the model’s explanatory role while assigning actual implementation checks to the relevant authorized boundary, with synthetic fixtures and no real attendee data.

Common errors and fixes

Every stored field is treated as public

Why it happens: The asset model ignores meaning and disclosure requirements.
How to fix it: Classify fields and define allowed response projections.
Prevent it next time: Review data categories whenever a new output path is added.

A network diagram is called a trust model

Why it happens: Arrows do not identify authority or validation decisions.
How to fix it: Label sources, controlled values, and trust assumptions.
Prevent it next time: Require a concrete review question for important boundary crossings.

A client sets its own trusted-source label

Why it happens: Provenance metadata is accepted from the wrong boundary.
How to fix it: Establish trusted context through the reviewed integration.
Prevent it next time: Test client claims and trusted facts as separate inputs.

Check your understanding

1. An export moves from direct response to a stored download. Which model questions change?

Show worked solution

Add the result store, retrieval path, lifetime, and permission check at download time. Determine whether reassigned or removed organizers retain access and whether storage and logs contain contact data. Keep existing request-time checks, but do not assume they establish later download authorization.

2. Does trusted storage make a workshop title safe for every output?