Skip to main content

Code Origin and Provenance

For many years, secure development rested on an implicit assumption:
code was written mostly by the team itself, deliberately and with understanding.

That assumption is no longer valid.

Today, a typical codebase results from a combination of:

  • code written locally;
  • code reused across projects;
  • adapted examples;
  • automated transformations;
  • suggestions and acceleration from support tools.

The result is that code now has multiple provenance, even when it resides in the same repository.

Why provenance matters​

Code provenance is not a philosophical question; it is a question of risk.

Without a clear understanding of the origin and context of a code fragment, risks arise such as:

  • inadvertent use of insecure patterns;
  • introduction of implicit dependencies;
  • incompatibilities with architectural decisions;
  • conflicts with existing security requirements;
  • legal or licensing risks.

Treating code of unknown provenance as “normal” is equivalent to accepting an external dependency without analysis - something that SbD-ToE explicitly rejects.

Internal code as an internal supply chain​

This addon introduces a key concept:

Code produced internally must be treated as part of the internal supply chain.

Just like external dependencies:

  • code has an origin,
  • a context,
  • a history,
  • and associated risk.

The difference is only the perimeter of control, not the need for validation.

This perspective creates direct coherence with Chapter 05 - Dependencies and Supply Chain, without duplicating its mechanisms.

Provenance is not authorship​

It is important to distinguish:

  • authorship: who wrote the code;
  • provenance: in what context it arose, under what assumptions, and with what degree of understanding.

A code fragment can be:

  • correctly written,
  • functional,
  • and still unsuitable for the context in which it is incorporated.

Secure development is concerned with suitability, not only with syntactic correctness.

Practical implications for development​

Assuming provenance implies that:

  • incorporated code must be understood, not merely tested;
  • incorporation decisions must be explicit;
  • exceptions must be recorded when understanding is partial;
  • human review becomes a governance mechanism, not only a quality one.

These implications are reflected directly:

  • in the validation rules,
  • in the lifecycle gates,
  • and in the evidence required for acceptance.

Closing​

By treating code as an artefact of controlled provenance, secure development no longer depends on the “average quality” of contributions and comes to depend on robust and verifiable processes.

This is the only model that scales when development becomes fast, distributed and assisted by advanced tooling.