Defect Management Flow
This article explains the common practice of handling defects in Enso
Step 1 - Connect
The defects flow starts with:
Building the asset inventory by connecting to SCM’s, DNS management, etc.
Scanning the inventory using AST’s according to the available assets (SAST, SCA, IaC, DAST, etc.) Enso comes out of the box with various built-in scanners that can cover all you need for your AppSec program.
Step 2 - Classify
Once the inventory is ready and assets are scanned, it’s time to classify the assets according to their business criticality. This step is critical to make sure that mitigation efforts are invested in the right areas. To do so, you can either classify assets manually by picking the relevant asset class from the inventory or build a classification policy that will classify assets automatically according to a predefined business logic.
It’s highly recommended to create an automated classification policy as an average inventory has thousands of assets and grows dynamically.
Step 3 - Define coverage
At this point, you already have scanned assets that are prioritized according to the scanners’ findings and the associated business impact (class). Now it’s time to ensure that the scanners are scanning all the essential assets. To do so, you should define a coverage policy. The coverage policy determines what assets are expected to be scanned per control. Assets that were not scanned as expected will get higher risk and thus higher priority. A coverage policy example can be “all assets under class A or B should be scanned at least once every 2 weeks for Gitleaks”.
Step 4 - Triage by priority
When the inventory is ready, classified and coverage policy is defined, you can move on and start mitigating potential risks. Before starting to actually resolve the findings, you would like to ensure that you’re handling the top priority defects first.
Our recommendation is to start with the riskiest asset first and with its top defects. For each defect, investigate the reported finding and rule out irrelevant findings by modifying the defect status to either dismissed or false positive. The remaining defects should be proceeded to resolution. To distribute work to the R&D teams, you can create Jira tickets on the defects after they have been triaged and found relevant.
To make the triaging process more efficient, you can build policy rules that will automatically identify irrelevant defects by source and content, and reduce the noise by either lowering the defects’ severity or by changing the defects’ status to false-positive or dismissed.
Step 5 - Check daily status
To make sure reported defects are being mitigated as expected, it is recommended to check daily on the status of critical defects with Jira tickets assigned.
To do so:
Go to the defects page
Filter by “Ticket URL” contains “atlassian” and “Status” is any of “Open” or “In progress”
Review the defects list starting from top
Step 6 - Watch trends
The last step of the defect management flow is tracking the AppSec program status and progress.
The main widgets you should be looking into include:
Posture score (the higher the better)
Defects trend
Overall SLA
Defect Aging
Control coverage
High Level Flow
Last updated
