Continuous Security

  1. Triage vulnerabilities within 24 hours to determine:
    1. Does the vulnerability actually apply to your application. Is it reachable, does the impact apply to your application, etc.
    2. Who reported the vulnerability? If the issue is reported through a bug bounty, customer, or penetration test, it is often more critical to solve compared to a security scanner
    3. If the vulnerability is valid, how likely is it to be exploited? Is there a public exploit, is the attack complex, is it easy to reach the vulnerable component?
    4. What impact would the vulnerability have if it were exploited? This is commonly done using impact to CIA (Confidentiality, Integrity, Availability)
  2. If the vulnerability does apply, assign a priority based on:
    1. Severity, usually based on the CVSS score. The higher the CVSS score, the higher priority the fix is
    2. How likely an exploitation of the issue is. If there is active exploitation or the possibility for it, higher priority could be assigned
  3. Develop a fix to the vulnerability - Of note, a vulnerability fix will typically apply to the latest release, but may also apply to older releases depending on your support model
  4. Determine a release strategy - Larger companies often follow a specific cadence for security releases, like Patch Tuesday, with out of band releases for critical issues. I've also seen monthly release cycles like Android security bulletin. The release cadence will vary a lot by company and release cycle preferences
  5. For fixing common vulnerabilities, there are a few details that might be good to discuss:
    1. Default to known secure patterns for development. For example, use parameterized SQL vs concatenation. Our security outputs do a great job of showing these approaches and linking to CWE resources to help here
    2. In addition to this, using DRY to standardize is helpful. For example, having a single class of SQL functions helps ensure all SQL queries use the same logic, avoiding mistakes in implementation
    3. Resources like OWASP, CWE, and NVD are often helpful for understanding these patterns
  6. Looking for variants on a security vulnerability is often advisable. If for example you find a SQL injection vulnerability, you should look at your code to try to identify if other examples exist of the same weakness