Learn how fictional teams inventory dependencies, protect build pipelines, verify artifacts, secure configuration, monitor drift, validate deployments, and retire unsafe components.
Lesson Progress
High School Intermediate • I9: Secure Coding Basics • Lesson 6 of 8
Readiness Check
0/5 ready
Professional Hook
A fictional application may use hundreds of direct and transitive components, a runtime, a base image, build tools, package registries, service identities, deployment templates, feature flags, certificates, and monitoring rules. A safe source review can still be weakened by a mutable image tag, broad build credential, unsupported runtime, debug setting, incorrect listener, or artifact that does not match the approved build.
Weak conclusion
A fictional scanner found a high-severity package advisory, so the entire application is compromised.
Strong conclusion
Confirm the exact component and version, source, reachability, privilege, exposure, controls, artifact, runtime, business consequence, update path, validation, and residual risk.
Objective 1
Explain how fictional dependencies, packages, lockfiles, registries, build tools, artifacts, images, runtimes, configuration, feature flags, deployment identities, and infrastructure settings affect application security.
Objective 2
Distinguish inventory, provenance, integrity, support status, known risk, reachability, exploitability, compensating controls, business exposure, remediation priority, and residual risk.
Objective 3
Review a fictional build and deployment pipeline for trusted sources, pinned versions, artifact verification, least privilege, secret isolation, approval gates, environment separation, rollback, and evidence.
Objective 4
Evaluate fictional runtime and infrastructure configuration for secure defaults, exposed services, debug settings, certificates, headers, identities, permissions, logging, drift, and ownership.
Objective 5
Create a professional fictional Dependency, Build, and Configuration Security Review with findings, owners, validation, monitoring, rollback, evidence gaps, residual risk, and closure criteria.
Why This Matters
Fictional security reviews are incomplete if they stop at source code. The reviewed source must produce the expected dependency graph, pass through a trusted build, create an identifiable artifact, deploy through an approved identity, receive secure configuration, run on supported infrastructure, produce healthy evidence, and remain aligned with the baseline after change.
Dependency Lifecycle
A fictional team documents why a new library, package, service, runtime, or image is required.
Controls
Business need, owner, approved capability, data access, environment, alternatives, maintenance plan, and retirement condition.
Evidence
Design record, owner approval, dependency request, architecture link, and intended consumers.
Failure mode
A package is added for convenience without clear purpose, owner, review, or removal plan.
The fictional component comes from an approved registry, repository, vendor, or internal build system.
Controls
Trusted source, exact package identity, namespace review, publisher or owner, transport protection, and registry policy.
Evidence
Registry record, source URL category, owner, package identity, signature or integrity metadata, and approval.
Failure mode
A similarly named or untrusted package is accepted because the name looks familiar.
The fictional build resolves exact versions and records them for repeatable installation.
Controls
Exact versions, lockfile, integrity metadata, transitive inventory, reproducible install, and update policy.
Evidence
Manifest, lockfile, resolved dependency graph, integrity values, and clean-build comparison.
Failure mode
Broad version ranges or floating tags allow different components to appear across builds.
The fictional team reviews support status, known risk, maintenance health, reachability, privilege, data access, and business exposure.
Controls
Advisory review, support lifecycle, reachable code analysis, usage map, compensating controls, priority, and owner.
Evidence
Inventory, advisory record, code or architecture usage, runtime evidence, tests, and risk decision.
Failure mode
Every advisory is treated as proof of exploitation or every unused-looking package is ignored without evidence.
The fictional component is installed and used through a controlled pipeline with security and regression validation.
Controls
Isolated build, least-privileged identity, no uncontrolled scripts, secret isolation, tests, policy gates, and artifact verification.
Evidence
Build ID, tool versions, dependency graph, test results, policy results, and generated artifact hash.
Failure mode
Package installation executes with broad credentials, network access, or access to unrelated secrets.
The fictional approved artifact is deployed with the reviewed dependency and runtime configuration.
Controls
Artifact identity, environment policy, runtime version, health checks, logging, monitoring, rollback, and owner routing.
Evidence
Deployment record, artifact digest, runtime inventory, configuration comparison, health metrics, and alerts.
Failure mode
A different artifact, runtime, or package set reaches production than the one that passed review.
The fictional team evaluates new versions, known risks, support deadlines, and compatibility changes through controlled change.
Controls
Prioritization, staged update, compatibility tests, negative tests, deployment validation, monitoring, and rollback.
Evidence
Change ticket, before and after versions, tests, risk decision, deployment, and old-version removal.
Failure mode
Updates are delayed indefinitely or installed directly in production without validation.
The fictional component, runtime, image, service, rule, secret, and configuration are removed when no longer needed.
Controls
Usage confirmation, manifest cleanup, lockfile update, image cleanup, secret and identity removal, inventory update, and monitoring.
Evidence
Retirement ticket, repository change, clean build, deployment inventory, access denial, and owner sign-off.
Failure mode
Unused components and vulnerable runtimes remain in images, caches, recovery paths, or dormant services.
Risk Prioritization
Review fictional advisories, end-of-support dates, maintainer status, and available fixed versions.
Lower concern
Supported component, no relevant known issue, timely maintenance, and approved source.
Higher concern
Unsupported or abandoned component, relevant advisory, no fix, or uncertain publisher ownership.
Evidence
Advisory record, version, support notice, maintainer history, and owner review.
Determine whether the fictional application loads, calls, or exposes the affected code path.
Lower concern
Component exists only in development tooling or an unreachable optional path with evidence.
Higher concern
Component runs in production on ordinary requests, file processing, authentication, or privileged workflows.
Evidence
Build graph, source reference, runtime trace, route map, feature flag, and safe test.
Evaluate what the fictional component or workload can read, change, execute, or reach.
Lower concern
Isolated process with narrow read-only access and no secrets or sensitive data.
Higher concern
Broad service identity, write access, secret access, production network reach, or privileged host capability.
Evidence
Identity policy, file and network permissions, secret access, service map, and runtime configuration.
Review which fictional users, routes, files, messages, integrations, and environments can reach the component.
Lower concern
Small test-only workflow with approved users and no nonpublic data.
Higher concern
Internet-facing route, broad authenticated population, third-party input, or critical shared service.
Evidence
Route inventory, user population, environment map, listener, integration, and data flow.
Assess how fictional isolation, validation, least privilege, network policy, feature flags, monitoring, and rollback reduce risk.
Lower concern
Independent controls are present, tested, monitored, and owned.
Higher concern
Controls are missing, inconsistent, bypassable, untested, or unsupported by evidence.
Evidence
Architecture, configuration, code review, tests, policy results, and monitoring.
Connect fictional technical exposure to privacy, integrity, availability, evidence, decision, and trust impact.
Lower concern
Minor internal inconvenience with easy recovery and no sensitive data.
Higher concern
Nonpublic data, privileged action, critical support workflow, export, payment, identity, or prolonged outage.
Evidence
Business owner, data classification, workflow dependency, recovery requirement, and impact statement.
Estimate fictional compatibility, migration, testing, deployment, monitoring, and rollback needs.
Lower concern
Small isolated update with strong automated coverage and reversible deployment.
Higher concern
Breaking runtime change, many consumers, data migration, unknown owners, or limited rollback.
Evidence
Dependency graph, compatibility notes, consumers, tests, deployment design, and rollback plan.
Measure how strongly fictional inventory, build, runtime, test, and operational sources support the conclusion.
Lower confidence
Stale inventory, missing lockfile, unverified artifact, incomplete logs, or uncertain runtime usage.
Higher confidence
Independent source, build, deployment, runtime, test, and business evidence agree.
Evidence
Source count, timestamps, artifact identity, runtime inventory, tests, monitoring, and evidence gaps.
Core Concept
Source
Which fictional repository, registry, publisher, revision, package, image, or vendor is approved?
Component
Which fictional direct or transitive version, runtime, tool, service, or image is actually required and reachable?
Build
Which fictional runner, identity, secret scope, tools, tests, policies, and commands produced the output?
Artifact
Which fictional digest, inventory, provenance, repository, access, and retention identify the approved output?
Runtime
Which fictional environment, configuration, identity, listeners, certificates, flags, permissions, and dependencies are active?
Evidence
Which fictional tests, deployment records, runtime inventory, drift, monitoring, business checks, rollback, and owner decisions prove the result?
Build Pipeline
The fictional pipeline retrieves approved source from a protected repository and exact reviewed revision.
Controls
Protected branch, reviewed change, signed or verified revision where used, least-privileged checkout identity, and no untrusted fork secrets.
Evidence
Commit reference, pull request, approvals, repository policy, pipeline trigger, and source digest.
Failure mode
A branch, fork, or unreviewed revision can trigger a privileged build.
The fictional build uses approved runner images, compilers, package managers, and security tools.
Controls
Pinned runner image, supported tool versions, isolated workspace, clean environment, and limited network and host access.
Evidence
Runner image digest, tool inventory, environment policy, job identity, and clean-run record.
Failure mode
Mutable runner images or shared workspaces preserve unknown tools, credentials, or artifacts.
The fictional build installs the exact dependency graph from approved sources.
Controls
Lockfile enforcement, integrity verification, trusted registry, script policy, cache validation, and transitive inventory.
Evidence
Manifest, lockfile, registry, integrity result, install log, cache ID, and graph.
Failure mode
Install scripts receive broad secrets or floating versions resolve differently between builds.
The fictional job receives only the credentials required for the current stage.
Controls
Stage-specific identity, environment separation, short-lived credentials, no secrets for untrusted contributions, and redaction.
Evidence
Job identity, granted secret names, audience, environment, access event, and duration.
Failure mode
Every build step can read production secrets, signing keys, and deployment credentials.
The fictional application is compiled, packaged, and validated in a controlled workspace.
Controls
Reproducible commands, security and functional tests, policy gates, resource limits, isolated output, and no manual replacement.
Evidence
Build ID, command category, test results, policy results, dependency graph, and output digest.
Failure mode
A failed test is ignored or an artifact is manually rebuilt outside the reviewed pipeline.
The fictional output is stored immutably with identity, provenance, integrity, and retention metadata.
Controls
Immutable repository, artifact digest, build identity, provenance, restricted signing, retention, and access review.
Evidence
Artifact ID, digest, build reference, signature or attestation metadata, owner, and repository record.
Failure mode
Artifacts can be overwritten, replaced, or signed by unrelated identities.
The fictional deployment selects the approved artifact and applies version-controlled environment configuration.
Controls
Artifact digest, deployment identity, environment approval, configuration template, secret references, migration plan, smoke tests, and rollback.
Evidence
Release ticket, artifact ID, environment, configuration digest, deployment result, and health check.
Failure mode
A mutable tag or local artifact deploys instead of the reviewed output.
The fictional team verifies runtime, configuration, dependency, business, monitoring, and rollback health.
Controls
Runtime inventory, configuration comparison, positive and negative smoke tests, source health, business metrics, and rollback readiness.
Evidence
Runtime versions, drift report, test results, alerts, business checks, and owner approval.
Failure mode
The release is considered complete when the deployment command succeeds.
Secure Configuration
Use fictional supported versions with secure defaults and documented update ownership.
Review
Version, support date, debug state, modules, startup options, memory and process limits, and owner.
Risk
Unsupported runtime, debug mode, unnecessary modules, unsafe flags, or inconsistent environment values.
Validation
Approved version runs, debug detail is absent, unsupported modules are disabled, and runtime inventory matches the baseline.
Expose only fictional required hosts, ports, protocols, routes, health endpoints, and administrative interfaces.
Review
Listeners, bind addresses, proxy routes, management paths, health checks, firewall or policy, and ownership.
Risk
Unnecessary management, debug, metrics, database, or internal service endpoints become reachable.
Validation
Approved paths work while unused ports, unapproved hosts, and administrative routes are denied.
Protect fictional transport with approved protocols, certificates, names, trust, renewal, and rollback.
Review
Certificate inventory, issuer, names, expiry, protocol policy, private-key handling, automation, and recovery.
Risk
Expired, mismatched, weak, shared, or unmanaged certificates create trust and availability failures.
Validation
Production and recovery paths trust the new certificate, old values retire safely, and monitoring alerts before expiry.
Apply fictional browser and session protections consistently across routes, redirects, errors, APIs, and legacy paths.
Review
Transport policy, content policy, framing, content type, referrer behavior, cache controls, cookie attributes, scope, and lifetime.
Risk
Coverage gaps on errors, redirects, static routes, subdomains, or legacy services weaken otherwise strong controls.
Validation
Expected headers and cookie attributes appear on all reviewed paths and negative browser conditions fail.
Reference fictional managed secrets and validate all nonsecret configuration through approved schemas and baselines.
Review
Secret references, environment separation, defaults, required values, redaction, rotation, and owner.
Risk
Hard-coded secrets, missing values, unsafe defaults, production reuse, environment dumps, or broad secret access.
Validation
Approved values load, missing or invalid configuration blocks startup safely, and no secret value appears in evidence.
Grant fictional processes only required files, secrets, databases, queues, services, and deployment actions.
Review
Runtime identity, file permissions, network access, secret policy, downstream operations, environment, and review date.
Risk
Shared or privileged identities expand blast radius and weaken attribution.
Validation
Required operations pass while unrelated resources, environments, and actions are denied.
Use fictional flags as controlled release tools rather than authorization or permanent hidden configuration.
Review
Owner, environment, audience, default, expiry, dependency, rollback, monitoring, and cleanup date.
Risk
Old flags preserve unsafe code, expose features to wrong users, or create inconsistent paths.
Validation
Approved audiences and environments receive the feature, wrong users do not, and rollback behavior is tested.
Detect fictional missing sources, baseline differences, unsafe changes, expired components, and owner gaps.
Review
Source inventory, expected event volume, parser health, drift rules, certificate and dependency monitors, alert owner, and retention.
Risk
The environment changes silently after release or critical evidence disappears.
Validation
Known safe drift and source-loss tests create owned alerts and the environment can be restored to baseline.
Artifact Verification
Confirm the fictional artifact maps to the reviewed source revision and pull request.
Evidence
Commit or revision, repository, pull request, approvals, pipeline run, and source digest.
Failure signal
The artifact lacks source reference or maps to an unreviewed branch.
Validation
Rebuild from the recorded source and compare expected artifact identity.
Confirm the fictional artifact contains the approved direct and transitive dependency graph.
Evidence
Manifest, lockfile, component inventory, package source, versions, and integrity metadata.
Failure signal
Runtime inventory contains undeclared or unexpected versions.
Validation
Compare clean build, stored artifact inventory, and deployed runtime inventory.
Confirm the fictional artifact was produced by the approved pipeline, runner, tools, and workload identity.
Evidence
Build ID, runner image, tool versions, job identity, policy results, and timestamps.
Failure signal
A local or manual build replaces the pipeline output.
Validation
Only approved build identities can publish to the artifact repository.
Confirm the fictional artifact digest and optional signing or attestation metadata remain consistent.
Evidence
Digest, repository record, signature or attestation metadata, access log, and retention.
Failure signal
The artifact can be overwritten or digest differs between build and deployment.
Validation
Deployment rejects an artifact whose identity or integrity does not match policy.
Confirm the fictional artifact does not contain embedded secrets, credentials, private keys, or environment dumps.
Evidence
Approved scanning result, image or package review, build logs, secret references, and exception record.
Failure signal
Inert placeholder secret values appear in layers, files, metadata, or source maps.
Validation
Test placeholders are absent and runtime retrieves values only through approved references.
Keep fictional environment-specific values outside the reusable artifact where appropriate.
Evidence
Artifact contents, deployment template, environment values, secret references, and configuration schema.
Failure signal
Production endpoints, secrets, or flags are embedded in a shared artifact.
Validation
The same approved artifact can deploy to test and production with separate governed configuration.
Store the fictional artifact in an approved immutable repository with access, retention, and cleanup rules.
Evidence
Artifact repository, owner, permissions, retention class, access events, and deletion policy.
Failure signal
Artifacts are copied through personal drives, chats, or mutable shared folders.
Validation
Unauthorized publish and overwrite attempts fail; expired artifacts retire according to policy.
Confirm the fictional deployed runtime uses the exact approved artifact and expected configuration.
Evidence
Deployment ID, artifact digest, runtime image or package ID, configuration digest, and health result.
Failure signal
The deployment references a mutable tag or unknown local package.
Validation
Runtime inventory and deployment evidence match the release record.
Exceptions
A fictional component cannot be updated immediately because a critical workflow depends on an older interface.
Required controls
Exact scope, reachability review, isolation, least privilege, monitoring, owner, update plan, deadline, and rollback.
Evidence
Business dependency, technical blocker, affected routes, tests, compensating controls, and approval.
Closure
Update or remove the component, validate workflows, retire the exception, and confirm no old version remains.
A fictional service requires a rapid setting change to restore availability.
Required controls
Narrow change, authorized owner, before-and-after evidence, backup, extra monitoring, rollback, and follow-up review.
Evidence
Incident or change record, exact setting, approver, deployment, health result, and due date.
Closure
Return to the approved baseline or formally update the baseline after full review and testing.
A fictional service temporarily remains on an older supported or nearly unsupported runtime.
Required controls
Limited exposure, isolated network, reduced privileges, dependency freeze, enhanced monitoring, migration owner, and milestone dates.
Evidence
Runtime inventory, route scope, controls, test plan, migration progress, and owner review.
Closure
Move to the approved runtime, remove the old image and service, validate, monitor, and retire the exception.
A fictional rollback flag temporarily keeps a legacy implementation available.
Required controls
Restricted audience, short expiry, clear owner, monitoring, safe defaults, no authorization reliance, and cleanup ticket.
Evidence
Flag policy, environment, audience, default, usage, tests, expiry, and owner.
Closure
Remove the old code and flag after validation and rollback confidence are complete.
Correlated Remediation Timeline
08:00
Inventory
A fictional reporting application records direct and transitive packages, runtime, base image, owners, and environments.
The dependency and runtime scope is established.
08:10
Advisory review
A fictional image-processing package has a relevant high-severity advisory with an available fixed version.
Known risk exists, but priority still requires reachability and exposure review.
08:20
Usage review
The package is loaded only by a file-preview worker that processes teacher-uploaded documents.
The affected code is reachable through a defined workflow.
08:25
Privilege review
The worker uses a shared service identity with read and write access to all support-document buckets.
The workload has broader access than required.
08:30
Build review
The lockfile pins the vulnerable package, but the worker image uses a mutable base-image tag.
Dependency identity is repeatable while base-image identity is not.
08:35
Configuration review
The worker runs with debug logging and includes complete document names in standard events.
A configuration and privacy weakness increases exposure.
08:40
Containment
New preview processing is paused, the worker identity is reduced to one test bucket, and debug logging is disabled.
Narrow controls reduce immediate exposure while preserving unrelated application workflows.
09:00
Remediation build
The fixed package and pinned base image are built through the approved pipeline with a named worker identity.
Dependency, artifact, and service-identity controls are improved together.
09:15
Artifact review
The fictional image digest, source revision, dependency graph, build ID, tests, and provenance metadata are recorded.
The artifact can be traced from source to deployment.
09:30
Positive test
Approved document preview succeeds in the isolated test environment.
Legitimate workflow remains available.
09:35
Negative test
Unsupported files, oversized files, wrong-tenant objects, unrelated buckets, debug mode, and old package versions are denied or absent.
Several unsafe and unauthorized conditions are controlled.
09:45
Deployment
The approved image digest and version-controlled configuration deploy through the production pipeline.
The reviewed artifact and settings move into production.
10:00
Runtime validation
Production inventory matches the approved package, base image, runtime, identity, listeners, and configuration.
The deployed state matches the release evidence.
Day 7
Monitoring
Preview health is stable, no old-image use appears, source delivery is normal, and no configuration drift is detected.
Short-term operational evidence supports remediation.
Day 30
Owner review
The team confirms update policy, image retirement, service permissions, alert ownership, and exception closure.
Lifecycle ownership continues after deployment.
Key Vocabulary
A fictional library, package, module, framework, runtime, service, image, or component required by an application or build.
A fictional file recording exact resolved dependency versions and integrity metadata for repeatable installation.
A fictional record of direct and transitive components, versions, sources, owners, environments, support status, and usage.
A fictional build output such as an application bundle, package, image, binary, deployment archive, or configuration package.
Fictional assurance that the reviewed artifact is the same one produced, approved, stored, and deployed without unauthorized change.
A fictional automated process that retrieves source, dependencies, tools, secrets, tests, builds, signs, stores, and deploys artifacts.
A fictional approved set of runtime, operating, network, application, header, certificate, logging, identity, and permission settings.
A fictional difference between the approved baseline and the actual deployed environment.
The fictional risk remaining after updates, isolation, configuration, monitoring, exceptions, and validation are considered.
Fake Dashboard
Training dashboard for the fictional Meadowbrook environment.
Inventoried components
286
Fictional direct and transitive packages, tools, runtimes, base images, services, and deployment components.
Verified artifacts
18
Artifacts linked to reviewed source, dependency graph, build identity, tests, digest, repository, and deployment.
Open findings
7
Relevant advisory, mutable image tag, broad service identity, debug setting, listener, drift, and exception cases.
Fake SOC Alert
Source: Fake Dependency and Build Review Console • Time: 08:35 AM
Fake Log Panel
08:00 INVENTORY packages='recorded' runtime='recorded' base_image='recorded' 08:10 ADVISORY package='image-worker-lib' severity='high' fixed_version='available' 08:20 REACHABILITY workflow='teacher_document_preview' reachable='true' 08:25 IDENTITY worker='shared' bucket_scope='all_support_documents' 08:30 BUILD lockfile='pinned' base_image_tag='mutable' 08:35 CONFIG debug='true' document_names_in_logs='true' 08:40 CONTAIN previews='paused' identity_scope='test_bucket' debug='disabled' 09:00 REMEDIATE package='fixed' base_image='digest_pinned' identity='named' 09:15 ARTIFACT source='linked' graph='linked' build='linked' digest='recorded' 09:30 POSITIVE_TEST approved_preview='pass' 09:35 NEGATIVE_TEST unsupported='deny' oversized='deny' wrong_tenant='deny' unrelated_bucket='deny' 09:45 DEPLOY artifact_digest='approved' config='version_controlled' 10:00 RUNTIME_VERIFY package='fixed' image='approved' identity='least_privileged' drift='0' DAY7 MONITOR health='stable' old_image_use='0' source_health='normal' DAY30 REVIEW update_policy='confirmed' old_image='retired' exception='closed'
Training note: this is fake data for defensive analysis practice only.
Analyze the Evidence
Common Mistakes
Safe Practice Lab
Fictional Evidence Set
Review forty-eight supplied fictional records covering manifests, lockfiles, transitive graphs, registries, advisories, support status, reachability, runners, tools, identities, secrets, builds, tests, artifacts, images, runtimes, configuration, deployments, drift, exceptions, monitoring, rollback, and owners.
Required Analysis
Scenario Decision Lab
A fictional package scanner reports a high-severity advisory, but the team has not confirmed the exact runtime version, reachability, privileges, or affected workflow.
Scenario Decision Lab
A fictional operator disabled a failing health check directly in production, but the version-controlled configuration still enables it.
Defender Habits
Check Your Understanding
Choose your answers first. Explanations appear only after submission.
Portfolio Prompt
Create a fictional Dependency, Build, and Configuration Security Review using at least forty-eight manifest, lockfile, dependency-graph, registry, advisory, support, reachability, runner, tool, identity, secret, build, test, artifact, image, runtime, configuration, deployment, drift, exception, monitoring, rollback, and owner records. Include a component inventory, risk matrix, pipeline map, artifact verification record, baseline comparison, findings, positive tests, negative tests, exceptions, evidence gaps, residual risk, and closure criteria.
Key Takeaways
Navigation