Legacy Violations Best Practices
Focus enforcement and remediation on the violations where they matter most
Configuring enforcement without breaking legacy applications
Focus reporting on the most important risk
Giving development time to remediate while alerting to new risk
Use Legacy Violations to accept application risk for legacy applications
Enforcement is a challenge when applications are onboarded periodically
Legacy applications, that are infrequently built, seldom have the bandwidth to remediate technical debt
Use Legacy Violations to accept the current risk of applications
Continuous Monitoring to monitor new risk as it is discovered
Use Legacy Violations to reduce noise when onboarding applications
The default configuration for Legacy Violations is on policies with a threat level of 7 or lower
This will effectively waive all risks with a lower threat
This allows development teams to focus on critical and high-risk violations that present the most risk to the organization
This configuration can be modified per policy
The default policy may be configured to accept all risks including policies that are set to fail
Enable Legacy Violations override for child Organizations and Applications
Legacy Violations typically should be configured at the root organization level
Allow Legacy Violations to be overridden at the organization level for teams that do not need it
Add Legacy Violations to the backlog
Legacy Violations are still risks that should be remediated
Add Legacy Violations to the backlog to ensure they still get addressed
Socialize when Legacy violations will be revoked
Legacy violations may be hidden in the scan report, however, the risk does not go away
As a best practice, legacy violations should have a plan for review, and the appropriate remediation actions made
The risk that will continue to be accepted is replaced with time-based waivers going forward
Applications may have their legacy violations revoked at any point, but this will have to be done manually through the UI