Skip to main content

Code Validation as a Process Risk Control

In modern development, the main risk no longer lies only in the complexity of the code, but in the way that code is introduced into the system.

As teams turn to extensive reuse, automation, assisted generation and frequent refactoring, the act of “writing code” ceases to be an exclusively deliberate process and becomes, in many cases, a mediated, accelerated and non-linear process.

In this context, code validation ceases to be an optional good practice and comes to play a central role:
controlling the risk of the development process.

Code is not trust - it is input​

One of the fundamental assumptions of this chapter is simple, but structural:

Code is not trustworthy by default, regardless of its origin.

The origin of code - human authorship, internal reuse, external libraries or support tools - is not a valid criterion for trust.
The only factor that turns code into an acceptable artefact is technical validation proportionate to risk.

This principle is consistent with the treatment given to:

  • external dependencies (Ch. 5),
  • architectural decisions (Ch. 4),
  • and security requirements (Ch. 2).

Secure development extends that logic to the code produced internally itself.

Validation as a process, not as an event​

Another common mistake is to treat validation as a one-off event - typically a final review before the merge.

In SbD-ToE, validation is understood as a progressive process, in which code passes through well-defined states, each one reducing the risk introduced:

  1. Proposed code
    Code not yet understood or validated, subject to plausible error.

  2. Reviewed code
    Code analysed by a human with technical knowledge, but not yet empirically validated.

  3. Validated code
    Code subjected to relevant technical validations (tests, static analysis, automated checks).

  4. Accepted code
    Code whose incorporation is an explicit decision, taken on by an identifiable role.

The absence of any one of these transitions is not neutral: it represents unmitigated risk.

Plausible error: the greatest enemy of secure development​

A large share of modern vulnerabilities do not result from obviously incorrect code, but from plausible error:

  • logic that “makes sense” but fails in edge cases;
  • undocumented implicit assumptions;
  • incorrect use of secure APIs;
  • subtle omissions of validation or error control.

These errors easily go unnoticed when:

  • the review is superficial;
  • trust in the origin of the code is excessive;
  • empirical validation is insufficient.

That is why validation in secure development does not look only for bugs, but for understanding.

Evidence as an acceptance criterion​

In SbD-ToE, no validation exists without evidence.

Accepting code implies being able to answer, after the fact:

  • who reviewed it;
  • what validations were run;
  • with what results;
  • and on the basis of what criteria the decision was taken.

That evidence does not exist for “future audits”;
it exists to discipline the present process and reduce systemic error.

Link to the lifecycle​

This addon defines the technical rationale for code validation.
Its practical application - gates, responsibilities and artefacts - is described in the chapter's 15-aplicacao-lifecycle.md.

Validation does not replace other practices of the Manual;
it works as a point of convergence between development, testing and governance.