Automate security and compliance scanning

Blue Yonder Airlines has a Node.js repository on GitHub named byair/booking-api with a package-lock.json file. The team wants to be notified automatically whenever a newly published security advisory affects any of its direct or transitive npm dependencies, without writing or changing any workflow.

What should you enable?

1. AThe dependency graph and Dependabot alertsDependabot alerts compare the dependency graph built from the manifest and lock file with the GitHub Advisory Database and raise an alert when a new advisory affects any direct or transitive dependency.
2. BDependabot version updates through a dependabot.yml fileVersion updates open pull requests to keep dependencies current on a schedule regardless of vulnerabilities, and they require adding a configuration file.
3. CCode scanning with CodeQL default setupCodeQL analyzes the repository's own source code, not known vulnerabilities in third-party packages.
4. DSecret scanningSecret scanning detects credentials committed to the repository and has no knowledge of dependency advisories.

Humongous Insurance builds container images in Azure Pipelines and pushes them to an Azure Container Registry named crhumongousprod. The pipeline must fail before the push if an image has any critical vulnerability. In addition, images already stored in crhumongousprod must be reassessed automatically when new vulnerabilities are disclosed, with findings shown in Microsoft Defender for Cloud.

Which two actions should you perform? Each correct answer presents part of the solution.

1. AAdd a step before the push that runs Trivy against the built image with --severity CRITICAL and --exit-code 1Trivy scans the local image in the pipeline, and a non-zero exit code on critical findings fails the job before the image reaches the registry.
2. BEnable the Microsoft Defender for Containers plan on the subscription that contains crhumongousprodDefender for Containers uses Microsoft Defender Vulnerability Management to scan registry images on push and reassess them continuously, and its findings appear as Defender for Cloud recommendations.
3. CEnable Dependabot version updates for the docker ecosystem on the DockerfileDependabot can propose base image tag updates, but it does not scan built images for vulnerabilities or block a pipeline.
4. DEnable content trust on crhumongousprodContent trust signs and verifies image provenance; it does not detect vulnerabilities in image contents.
5. EAdd CodeQL analysis tasks to the pipeline for the application source codeCodeQL finds weaknesses in first-party source code; it does not inventory operating system packages or libraries inside the image.

Southridge Video has a GitHub Enterprise Cloud organization named southridge with 60 private repositories and GitHub Secret Protection licensed for all of them. After a storage account key was found in a commit, the security team requires that commits containing supported secret types are blocked at the moment of git push, before they reach any repository, for every current and future repository. Developers must not be able to bypass the control by skipping a local tool.

What should you configure?

1. AEnable secret scanning only, so that alerts are raised after each pushSecret scanning alone detects secrets after they are already in the repository history, which is too late for the requirement.
2. BDistribute a pre-commit hook that runs a secret detection tool on developer workstationsClient-side hooks are useful but can be skipped or not installed, so they do not enforce the control server-side.
3. CApply an organization security configuration that enables secret scanning and push protection to all repositories, and set it as the default for new repositoriesPush protection scans pushes on the server and rejects ones that contain supported secrets before they are written, and a default security configuration applies it to every new repository automatically.
4. DAdd the dependency review action as a required status check on mainDependency review evaluates dependency changes in pull requests; it does not look for secrets and acts only at merge time.

Woodgrove Industrial has a C++ firmware repository named woodgrove/plc-firmware on GitHub. The code compiles only with a proprietary cross-compiler that is packaged in the container image ghcr.io/woodgrove/firmware-build:2026, and the image includes Git. The team must run CodeQL code scanning on every push to main, have CodeQL observe the real compilation, and upload results to the repository's code scanning alerts.

How should you configure the workflow?

1. AEnable CodeQL default setup for the repository and select C/C++Default setup runs on GitHub-hosted runners with its own build detection, so it cannot use the proprietary compiler in the custom image and the build would fail or be incomplete.
2. BDefine a job with container: ghcr.io/woodgrove/firmware-build:2026 and permissions security-events: write, then run actions/checkout, github/codeql-action/init with languages: c-cpp, the manual build commands, and github/codeql-action/analyzeRunning the job in the build container lets the CodeQL action trace the real compilation with the proprietary toolchain, and security-events: write allows the analyze step to upload SARIF results to code scanning.
3. CRun the build in the container with docker run, then run github/codeql-action/init and analyze on the runner host after the container exitsFor compiled languages CodeQL must observe the build while it runs; initializing CodeQL on the host after the build happened in a separate container gives it nothing to extract.
4. DAdd the Microsoft Security DevOps action with the trivy tool against ghcr.io/woodgrove/firmware-build:2026Trivy scans the image for vulnerable packages and misconfigurations; it does not perform CodeQL semantic analysis of the firmware source code.