Skip to main content

Remediating Violations Checklist

There are three main ways to remediate risky open-source components. You can upgrade to a less risky version, substitute that component for another component with the same functionality, or accept the risk. Here your development teams will apply these three strategies to reduce the risk in your applications. The steps below list a general order to address violations, however, some critical violations may need to be addressed separately from this cadence.


While it is possible to patch an open-source component to remove a security violation, we do not recommend it. Once you have modified an open source component your developers will need to maintain that secure version. If you're interested in fixing open-source components, consider contributing back to the original package.


  • Remove risk from your applications

    • Upgrade risky components

    • Waive non-applicable violations

    • Replace dangerous components

    • Accept necessary risk

Action Items

  1. Update components to less risky versions - Using the prioritization list from the Assessing Risk step, begin updating your open source components to versions without the security violations. Upgrading is the ideal way to remove a violation.

    • Use the Version Explorer to identify compatible versions - The Component Details Page offers a breaking changes tool to identify which versions you can upgrade to without introducing potential breaking changes.

  2. Determine if you are vulnerable - If you can't upgrade a component, the next step is to determine if you are vulnerable. Your application security team should be able to help.

  3. Waive non-applicable violations - If you are not vulnerable to a security risk, you can choose to waive the violation.

    1. Waivers for non-legacy applications should expire and be reviewed regularly. There is no guarantee that you will not become vulnerable to a security vulnerability in the future.

    2. Review our Waiver best practices for more information.

  4. Identify components for replacement - If there is an exploitable vulnerability in your application, you may need to replace a risky component with another one that offers similar functionality.

  5. Waive un-remediable risk - Sometimes it is not possible to remediate a policy violation. In these cases you can apply a waiver to temporarily accept this risk.

    1. This waiver should expire and be reviewed regularly.

    2. This vulnerability should be monitored for suspicious activity.

Measuring Success

This can be measured with the Success Metrics script. Look at the Risk Ratio (total number of critical violations divided by the total number of onboarded apps). If your Risk Ratio is regularly going down, your total critical risk is being reduced, and you're ready to move on.