Continuous security testing case study: a lender that changes its systems every day
A security test describes a system on the day it was tested. This lender changed its systems 15 to 20 times a week, so each test was out of date soon after the report arrived. Meanwhile, the security review had turned into a three-day queue that developers resented.
Security as a three-day queue
The client is a fintech lender whose platform is made of more than 40 microservices (small, independent services that together run the business). It must meet OJK’s IT governance rules, OJK being Indonesia’s financial services regulator, and it was preparing for an ISO/IEC 27001 surveillance audit.
Every release waited in line for a security review. That slowed the business down, and it tempted teams to look for ways around the review. The lender wanted testing that kept up with its developers and still satisfied its auditors.
Moving the tests into the pipeline
We added security tests to the lender’s build and release pipeline, which ran on GitHub, GitLab and Jenkins. Every change now triggers checks of the code, of the open-source libraries it uses and of the API contracts. It also triggers live tests against a temporary copy of the system. Larger changes to infrastructure or applications trigger a full run, and each night a safe test profile checks the production systems that can be reached from outside.
The live tests are based on OWASP ASVS and the OWASP API Security Top 10. We agreed a simple rule with the lender: a release stops only for a confirmed critical or high finding, and that finding always arrives with an owner and a hint on how to fix it. Everything else becomes a ticket for the normal backlog.
What the pipeline caught
The clearest example came from a new version of the sign-up service. By adding role=admin to the sign-up request, a new user could make themselves an administrator. The pipeline caught this shortly after the code was committed and blocked the release before it reached production.
The test history also showed patterns that single tests would have missed. Critical findings in the login service came back four times. The cause was a shared library pinned to a version nine months out of date. A chart of every service over time showed most of them improving and three getting worse, so the next sprint focused on those three.
How the audit looks now
Developers no longer wait in a queue for security, and they have stopped trying to go around it. The library upgrade and new contract tests removed the recurring login flaw. For the ISO/IEC 27001 audit, the lender showed its pipeline logs and the per-service trend chart as evidence of ongoing testing.
Any team whose honest answer to “when was this last tested?” is “last quarter” has the problem this lender started with.