Q: We are a SaaS provider that follows a Scrum methodology, generally with two-week sprints. We do not handle cardholder data, but several clients are requiring vulnerability scans to show compliance to the PCI DSS standard.
How often do we need to run vulnerability scans against our product?
A: Many software providers are being required to be PCI compliant due to contractual requirements and/or because their application may be on the same network as PCI in scope systems, even though it may not store, process, or transmit cardholder data.
The 11.2 requirement of the PCI DSS requires vulnerability scans at least quarterly and after any significant change in the network and includes examples such as new system component installations and product upgrades. The Product Owner can likely determine whether changes to the product are a minor update, which likely wouldn’t mandate a vulnerability scan, or a major update, which likely would. A major update may include the migration to a new version of the development framework (e.g. moving from Rails 3.x to 4.x), or a critical piece of the application such as the authentication components. The 11.2 requirement focuses on detecting flaws at the application and network layers, but isn’t meant to be code scanning, which is covered more in Requirement 6: Develop and maintain secure systems and applications.
That being said, the higher the frequency of vulnerability scanning, the timelier the results will be and it is often easier to incorporate the results of the scan into the development life cycle.
Some organizations, particularly larger organizations, will continuously conduct vulnerability scans, often unannounced. There are benefits to aligning scan schedules with the two-week sprints, or perform monthly, which is generally more in-line with vendor patch updates. Either way, organizations that scan on a more frequent basis than quarterly tend to have an easier time achieving clean scan results. Additionally, limiting your scans to run on a quarterly basis increases the risk that a fix doesn’t get into the backlog in time.