Vulnerability Management

The correct answer involves implementing SCA validation during dependency declaration in manifest files before build execution, combined with a pre-approved dependency catalog maintained by the security team.

This approach most effectively addresses the workflow friction because:

1. Shift-Left Strategy: By validating dependencies at the manifest file level (such as package.json, pom.xml, requirements.txt), security checks occur at the earliest possible point - when developers are selecting and declaring dependencies, not after integration.

2. Pre-Approved Catalog: A curated catalog of vetted dependencies allows developers to make secure choices proactively. They can select from known-safe components, preventing vulnerable dependencies from ever entering the codebase.

3. Reduced Sprint Disruption: Since validation happens before developers invest time in integration work, they can choose alternative dependencies early without reworking code.

4. Proactive vs. Reactive: This shifts security from a blocking mechanism to an enabling one.

The option suggesting automated dependency updates during the build phase is problematic because automatically replacing dependencies can introduce breaking changes, compatibility issues, and untested code paths - this creates significant risk and doesn't give developers control over remediation.

The option proposing pull request gates with training still operates too late in the development cycle. While PR gates are valuable, developers have already written code by that point, so they still face the same late-stage replacement issue the organization is trying to solve.

The option suggesting CI phase scanning with parallel scanning of source and compiled artifacts represents the current state or even later-stage scanning. This doesn't address the core problem - it still catches issues after integration, causing the sprint disruption that development teams are complaining about.

The correct answer is to implement a streamlined emergency change process that requires documented risk assessment and post-implementation review within 48 hours.

This recommendation effectively addresses the identified pattern for several key reasons:

1. Balances Speed with Governance: Emergency changes exist because organizations need to respond quickly to urgent situations. A streamlined process acknowledges this operational reality while still maintaining appropriate controls.

2. Risk Assessment Requirement: By mandating documented risk assessment, the organization ensures that even urgent changes receive proper consideration of potential impacts. This addresses the root cause of the 40% failure rate - changes being made hastily with inadequate evaluation.

3. Post-Implementation Review: The 48-hour review requirement creates accountability and enables the organization to identify issues quickly, learn from mistakes, and improve future emergency change decisions. This is a core principle of continuous improvement in change management.

4. Practical Implementation: This approach is realistic and achievable, unlike solutions that would delay emergency response capabilities.

The other options have significant drawbacks:

• Requiring full CAB approval before implementation defeats the purpose of emergency changes entirely. When urgent security incidents or critical outages occur, waiting for the next scheduled CAB meeting could result in extended downtime, security breaches, or significant business impact.

• Automated approval based solely on requestor role and asset classification removes human judgment from the process. This could lead to inappropriate changes being approved automatically, potentially increasing the failure rate rather than reducing it.

• Pre-approving change categories during annual planning is too inflexible for the dynamic nature of emergency situations. Security threats and operational needs evolve throughout the year, making it impossible to accurately predict and pre-authorize all legitimate emergency change scenarios.