Defect Tracking

Benefit

Transparency of known security defects impacting particular applications

Activity

Introduce a common definition / understanding of a security defect and define the most common ways of identifying these. These typically include, but are not limited to:

• Threat assessments
• Penetration tests
• Output from static and dynamic analysis scanning tools
• Responsible disclosure processes or bug bounties

Foster a culture of transparency and avoid blaming any teams for introducing or identifying security defects. Record and track all security defects in a defined location. This location doesn’t necessarily have to be centralized for the whole organization, however ensure that you’re able to get an overview of all defects affecting a particular application at any single point in time. Define and apply access rules for the tracked security defects to mitigate the risk of leakage and abuse of this information.

Introduce at least rudimentary qualitative classificiation of security defects so that you are able to prioritize fixing efforts accordingly. Strive for limiting duplication of information and presence of false positives to increase the trustworthiness of the process.

Question

Do you track all known security defects in accessible locations?

Quality criteria

Answers

Benefit

Consistent classification of security defects with clear expectations of their handling

Activity

Introduce and apply a well defined rating methodology for your security defects consistently across the whole organization, based on the probability and expected impact of the defect being exploited. This will allow you to identify applications which need higher attention and investments. In case you don’t store the information about security defects centrally, ensure that you’re still able to easily pull the information from all sources and get an overview about “hot spots” needing your attention.

Introduce SLAs for timely fixing of security defects according to their criticality rating and centrally monitor and regularly report on SLA breaches. Define a process for cases where it’s not feasible or economical to fix a defect within the time defined by the SLAs. This should at least ensure that all relevant stakeholders have a solid understanding of the imposed risk. If suitable, employ compensating controls for these cases.

Even if you don’t have any formal SLAs for fixing low severity defects, ensure that responsible teams still get a regular overview about issues affecting their applications and understand how particular issues affect or amplify each other.

Question

Do you keep an overview of the state of security defects across the organization?

Quality criteria

Answers

Benefit

Assurance that security defects are handled within predefined SLAs

Activity

Implement an automated alerting on security defects if the fix time breaches the defined SLAs. Ensure that these defects are automatically transferred into the risk management process and rated by a consistent quantitative methodology. Evaluate how particular defects influence / amplify each other not only on the level of separate teams, but on the level of the whole organization. Use the knowledge of the full kill chain to prioritize, introduce and track compensating controls mitigating the respective business risks.

Integrate your defect management system with the automated tooling introduced by other practices, e.g.:

• Build and Deployment: Fail the build / deployment process if security defects above certain severity affect the final artifact, unless someone explicitly signs off the exception.
• Monitoring: If possible, ensure that abuse of the security defect in production environment is recognized and alerted.

Question

Do you enforce SLAs for fixing security defects?

Quality criteria

Answers