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.
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.”
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.
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: