Annex 6.2.1

AI/ML model training is part of the secure-development life cycle; the rules for that lifecycle govern training-data integrity, model provenance and pre-deployment validation that detect poisoned anomaly-detection models.

Secure-development discipline (cross-module review, integration testing, defensive coding) is the developmental control that surfaces colluding modules whose individual behaviour appears benign but whose composition produces malicious effect.

Modifications to authentication code (binary patches, hot-patches, service replacement) sit inside the secure-development envelope; the rules for code review, integrity verification and signed-build provenance are the controls that detect such modifications.

Boot memory artefacts are produced in the secure-development life cycle; the rules for that lifecycle govern signing, integrity protection and storage of boot-stage components.

Firmware updates and programmable-logic bitstreams produced internally are governed by the secure-development life cycle; outsourced firmware development inherits the same rules under Annex 6.2.3.

Secure-development rules embed defensive coding and review obligations that reduce the population of exploitable defects entering production.

Flight-software command/telemetry handlers, table loaders and file-transfer services live inside the secure-development life cycle the implementing regulation requires the entity to govern with explicit rules; defensive coding, review and integrity practices reduce the population of exploitable defects in those parsers.

Code-signing and integrity-verification practices required by the secure-development life cycle constrain which executable artefacts the runtime accepts, narrowing the malicious-code-introduction surface.

AI/ML model training is part of the secure-development life cycle; the rules for that lifecycle govern data integrity verification, model provenance and pre-deployment validation that detect poisoned training inputs.

Constant-time, branch-balanced cryptographic implementations are part of secure-development discipline; these implementation choices reduce timing-channel leakage at the source.

Secure-development discipline includes constant-time, branch-balanced cryptographic implementations and side-channel-resistant coding patterns that reduce timing- and power-channel leakage at source.

Secure-development implementations (masking, blinding, randomized scheduling) reduce the data-dependent leakage measurable through power analysis.

Constant-time implementation of cryptographic and authentication paths is a secure-development discipline that closes timing-channel exfiltration; the rules for that lifecycle govern adoption of these implementation patterns.

SDR DSP chains, framing logic and waveform configuration are produced inside the secure-development life cycle; rules for that lifecycle govern integrity protection on bitstreams and waveform packages so attacker-introduced subcarriers and covert framing are blocked at source.

Source code, test vectors, telemetry captures, build artefacts and configuration data live inside the secure-development life cycle; the rules for that lifecycle govern the integrity, access and protection controls that resist exfiltration of the development corpus.

Dependency confusion, typosquatting, poisoned base images and malicious build plug-ins all sit inside the build-and-tooling envelope the secure-development life cycle rules govern; those rules constrain how dependencies are pinned, mirrored, signed and verified.

Source manipulation before build, swapped signed binaries at distribution edges and subverted update metadata all fall inside the secure-development life cycle the entity must govern with explicit rules.

FPGA bitstreams, software flowgraphs and reconfigurable waveforms are produced through the entity's network-and-information-systems development pipeline; the secure-development rules govern how those artefacts are written, reviewed, signed and verified.

Source repositories, build steps and packaging tooling for flight-software updates live inside the secure-development life cycle, with explicit rules on how artefacts are produced and protected from manipulation.

Separation kernels and hypervisors are produced through the secure-development life cycle; the rules for that lifecycle govern the implementation quality of inter-partition communication, shared-memory windows and device-emulation paths that virtualization escape exploits.

Boot-stage code is produced inside the secure-development life cycle; integrity protection on boot artefacts and signed-build provenance are the development-side controls that resist persistent memory implants.

Backdoors planted during development are exactly what the secure-development life cycle is designed to prevent: code review, defensive coding standards and build-pipeline integrity reduce the population of hidden command handlers and alternate authentication paths.

Software backdoors are exactly the threat the secure-development life cycle counters: code review, mandatory authentication paths and signing/verification procedures resist hidden command handlers and alternate auth paths.

Source trees, command-handler implementations, build artefacts and patch mechanisms live inside the secure-development life cycle the implementing regulation requires the entity to establish; the rules and tooling specified there constrain who can read and copy the codebase.

Firmware images, OTA bundles, secure-boot configuration and anti-rollback policy are produced by the entity's network-and-information-systems development pipeline; the secure-development rules govern how those artefacts are stored, signed and protected from disclosure.

Crypto implementations live in the secure-development pipeline; the rules for source review, build provenance and artefact protection determine whether algorithm specifics leak through code-tree exposure.

Fault-management logic is implemented in flight code; the secure-development rules govern access to the FDIR source and its test harnesses, which are the principal leakage paths for safing-behavior reconnaissance.

FSW development information lives entirely inside the secure-development life cycle the implementing regulation requires the entity to govern with explicit rules — that lifecycle is the protection envelope for every artefact this technique targets.

Secure-development rules govern the entity's development environment design, which is the very target the adversary enumerates.

Software-factory reconnaissance enumerates the very environment the secure-development rules govern: source location, dependency pulls, build/sign/store/promote flows.