Do GDPR & PCI DSS need me to security test every release?

One of the biggest drivers for software security, if not the biggest, is regulatory compliance.  There’s plenty of other considerations, such as bad press, loss of customers, and the remediation costs, but the penalties that come with breaching a regulation such as GDPR or PCI DSS can really hurt the business.

Leak personally identifiable information (PII) of a European citizen and the fines can be in the millions.  Breach PCI DSS, and you could lose your ability to issue new cards and get hit with more fines, which would really hurt a challenger bank.

Many regulations, including GDPR and PCI DSS, requires security testing to be performed before updates are released to the public.

What does GDPR say about software security?

GDPR has the ‘security principal’ in their advisories (https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/security/ ) which requires “ you to have a process for regularly testing, assessing and evaluating the effectiveness of any measures you put in place”.

GDPR doesn’t dive too far into technicality, however, it does state the following which applies to software you develop - “undertake this through a number of techniques, such as vulnerability scanning and penetration testing”.

GDPR states “you are required to undertake tests of security measures on a regular basis.” But how often does this mean development teams should run security testing? It is understood that security testing should be undertaken any time you modify software systems holding or processing PII data.

It’s not just about identifying the issues, GDPR states you need to have fixed the issues in software systems that are going to process your PII data - “you should document the results and make sure that you act upon any recommendations, or have a valid reason for not doing so, and implement appropriate safeguards. This is particularly important if your testing reveals potential critical flaws that could result in a personal data breach.”

What does PCI DSS say about software security?

The PCI DSS standard, version 3.2, contains section 6.3.2, which states coding vulnerabilities must be identified, manually or through automation, with appropriate remedies applied, before release.

The standard goes on to say that appropriate corrections need to be implemented prior to the software released into a production environment.

How can compliance security checks keep up with Agile/DevOps?

Manual security testing can't keep up and be cost-effective, especially not at scale, and the time it can take to set up automated testing can prevent it from ever happening.

This is why the Uleska Platform automatically wraps many forms of vulnerability scanning quickly and easily into DevOps and Agile software development processes.  When security becomes a blocker, either due to manual steps, or delays in setting up testing, then organisations run the risk of those daily/weekly releases falling foul of compliance issues.

The pre-built automation, orchestration, and integrations of many popular commercial and open source security testing tools in the Uleska Platform allows you to:

•  easily and efficiently meet your compliance targets by automatically executing security testing before every release.
• development teams to wrap security testing into their existing software development processes, finding security issues quickly, and fixing easily before release.
• Save time by automating those manual setups, execution, and reporting tasks and automate with every build or release. Remove the complexity of security testing.

‍