Exception Handling
Gomboc helps teams remediate security and compliance issues directly in code. In some cases, however, applying a code fix is not the right action. For example, a finding may already be mitigated by another control, may not apply to a specific environment, or may require a temporary business exception.
Use Exceptions to exclude specific Gomboc rules from enforcement in selected Policy Sets, while keeping a clear record of why the exception exists.
When to Use an Exception
Create an exception when a finding is valid but should not be remediated by Gomboc right now.
Common examples include:
The risk is already mitigated by another approved control, such as a WAF, network policy, compensating control, or platform guardrail.
The finding is relevant, but the team has accepted the risk for a documented business reason.
The rule does not apply to the architecture or environment covered by the selected Policy Set.
The responsible team is handling the issue through another approved workflow.
The finding is creating noise that prevents teams from focusing on actionable fixes.
Do not use exceptions as a shortcut to hide issues that still need remediation. If the underlying code should be fixed, use Gomboc’s remediation workflow instead.
What an Exception Does
An exception excludes one or more rules from one or more Policy Sets.
When a future scan runs, Gomboc resolves the workspace’s Policy Sets, then filters out the rules covered by the exception. Findings and fixes from those excluded rules are not shown in the scan results for the affected Policy Sets.
Exceptions are rule-based. This means an exception may suppress all findings from that rule within the selected Policy Set, not only the specific finding or line of code you were viewing when you created it.
Before You Create an Exception
Before creating an exception, review:
The rule: confirm which Gomboc rule is generating the finding.
The affected Policy Set: confirm where the exception should apply.
The business reason: document why remediation is not required or not appropriate.
The impact: understand that future findings from the same rule may be hidden for the selected Policy Set.
Ownership: make sure the exception aligns with your organization’s security and compliance process.
Create an Exception from a Finding
Open the relevant finding or remediation report.
Expand the section that shows the applied rules.
Click Create Exception for the rule you want to exclude.
Select the Policy Set where the exception should apply.
Add a clear reason explaining why the exception is being created.
Submit the exception.
Use a specific reason that will still make sense during a later audit or review. For example:
This service is protected by an approved external WAF rule. The platform security team has accepted this compensating control for the production workspace.
Avoid vague reasons such as:
Not needed.
Create an Exception from the Exceptions Page
If your account has access to the Exceptions page, you can also create exceptions directly from there.
Open Exceptions from the main navigation.
Click Create an exception.
Enter one or more rule IDs.
Select one or more Policy Sets.
Add a reason.
Submit the exception.
The Exceptions page also shows active exceptions, including the requester, creation date, affected rules, affected Policy Sets, and reason.
Revoke an Exception
Revoke an exception when it is no longer needed.
Open the Exceptions page.
Find the relevant exception.
Click the delete or trash icon.
Confirm the deletion.
After the exception is removed, future scans will apply the rule again wherever it is included by the workspace’s Policy Sets.
Best Practices
Keep exceptions narrow. Apply them only to the Policy Sets where they are needed.
Write audit-friendly reasons that explain the compensating control, risk decision, or business context.
Review exceptions regularly so temporary decisions do not become permanent blind spots.
Prefer remediation when the code can be safely fixed.
Be careful when selecting broad Policy Sets, because the exception may suppress future findings from the same rule across that Policy Set.
Coordinate with Security or Compliance before creating exceptions for high-risk or compliance-mapped policies.
Example
A finding recommends enforcing SSL connections for a database instance. Your team confirms that this environment is protected by another approved control and that changing the IaC right now would break a legacy integration.
In this case, you can create an exception for the specific Gomboc rule in the relevant Policy Set and include a reason such as:
Legacy integration requires the current setting until Q3 migration is complete. Risk is tracked in the security exception register and mitigated by network-level access controls.
Future scans using that Policy Set will skip findings from the excepted rule until the exception is removed.
Important Note
Exceptions reduce noise, but they also reduce visibility. Use them deliberately, document the reason clearly, and remove them when the exception no longer applies.
Last updated