Secure AI Development
Secure AI development
This domain tests whether security is designed into AI builds rather than bolted on after training. Questions cover the secure development lifecycle, supply-chain integrity and secure serving.
Core rules
- Threat model early: data ingestion, feature computation, training, registry, serving API, tools and downstream consumers.
- Integrate security into CI/CD: SAST, dependency and container scanning, secret scanning, infrastructure-as-code checks, mandatory review for pipeline changes.
- Supply chain: pin dependency versions, verify model hashes and signatures (for example Sigstore/cosign), prefer safetensors over pickle formats, and record provenance in an ML-BOM or SBOM.
- Isolate training and build environments; no production credentials in notebooks; least-privilege service accounts.
- Harden serving: authentication and authorization, rate limits, input size limits, schema validation, output encoding, and no raw model errors returned to callers.
- Align with NIST SSDF practices and treat model artifacts as release artifacts requiring approval.
Worked example
A team pulls a community model from a public hub. Correct sequence: pin an immutable revision, check the published hash, scan the artifact in a sandbox, load with a non-pickle format, review the model card for licence and data provenance, record all of it in the registry, and only then promote to staging behind an authenticated gateway. Reasoning: the artifact is executable content in many formats, so it is a supply-chain dependency, not a download.
Traps
- Trusting hub artifacts and unpinned "latest" tags.
- Reusing developer credentials in training jobs that can reach production data.
- Treating the inference endpoint as trusted internal traffic.
- Scanning code but never scanning model files.