How a US fintech went from manual laptop releases to a secure 10-minute pipeline
A US accounts-receivable automation fintech released by hand from one developer's laptop. Triotech built a secure 10-minute pipeline, moved the platform to AWS, fixed most of thousands of vulnerabilities and saved about $35K a month.
The situation
The client automates accounts receivable for more than 250 business customers, each running its own instance of the platform. The platform holds invoices, payment data and customer information, and the company had to meet SOC 2 requirements to keep winning and keeping customers.
The biggest problem was how software reached customers. A developer built every release by hand on their own machine and deployed it manually to on-premise servers. A release took days, and if that developer was away, nothing shipped. Nobody could say exactly what had gone into a release, or who had changed what.
Behind the release problem was a security one. The codebase was about 20 years old, full of repeated code and outdated open-source libraries, and nothing checked any of it for vulnerabilities before it reached customers.
The infrastructure was the third problem. The platform ran on on-premise servers, and when the company began moving to AWS, developers created servers themselves with no plan to shut them down. Idle machines and unused SSD storage kept billing every month, and nobody owned them.
The constraint
- Financial data on the line. Invoices, payment data and customer information all ran through the platform.
- SOC 2 expectations. Auditors and customers expect controlled changes, managed vulnerabilities and restricted access, and none of that was in place.
- A 20-year-old codebase. Years of copied code meant the same flaw could exist in dozens of places, and old libraries carried known vulnerabilities.
- 250+ customer instances. Every release and every migration step had to reach each customer's own environment without breaking it.
- One person as the release process. Build and deployment lived in a developer's head, not in a system.
- A migration with customers still live. Workloads had to move from on-premise to AWS while customers kept using the platform.
- Invisible cloud waste. Nobody owned the servers developers had created, so nobody knew what could be switched off.
What we did
- Automated build and deploymentWe started with the biggest problem. Using Jenkins and Azure DevOps, we built one parameterized pipeline that replaced the manual laptop process. Choose the release: branch, version, target environment and database are selected as parameters, not typed by hand. Build and test: the pipeline restores NuGet packages, compiles the code and runs automated tests (MSTest). Package: each release becomes a versioned artifact, so it is always clear what shipped. Deploy: the release goes to the target customer instances, and database scripts run automatically as part of the deployment. Every one of the 250+ customer instances now deploys the same way, with no developer's laptop involved and a full record of every release.
- Migrated from on-premise to AWSWith releases automated, we moved the platform off its on-premise servers and onto AWS. Assess: mapped what ran on the on-premise servers (applications, databases, scheduled jobs and their dependencies) so nothing was left behind. Design the target platform: Amazon EC2 for application servers and customer instances, Amazon ECR for container images of release builds, AWS Lambda for serverless functions, and Amazon RDS for managed databases, with backups and patching handled by AWS. Build it as code: defined the AWS infrastructure in CloudFormation, so every environment could be recreated identically and nothing was created by hand. Lock down access: created IAM roles and policies that gave each service and person only the access they needed. Move workloads: migrated applications and databases and pointed the pipeline at the new environments, so customers moved over through the same tested release process. Decommission: retired on-premise servers once their workloads were running on AWS.
- Shifted security left: SAST, DAST and SCA in every buildOnce releases ran through the pipeline, we built application security into it, so every build was checked automatically. SAST: Fortify on Demand scanned the source code for flaws such as injection, insecure data handling and broken authentication. DAST: Fortify on Demand tested the running application the way an attacker would. SCA: WhiteSource (now Mend) checked every open-source library against known vulnerabilities. Code quality and coverage: SonarQube flagged duplicated, risky and untested code. Any build with a critical finding went back to the developer to fix and rescan instead of going to customers.
- Found thousands of vulnerabilities and fixed most of themThe first scans of the 20-year-old codebase surfaced thousands of vulnerabilities, many repeated across copied code. We did not hand the client a list and leave. Our team fixed most of them. Triage: ranked findings by severity and exposure, starting with critical OWASP Top 10 issues in code that handled payment data and customer information. Fix at the root: where the same flaw appeared across copied code, we fixed the pattern everywhere it appeared, not one instance at a time. Upgrade vulnerable libraries: used Mend's findings to upgrade outdated open-source libraries to secure versions, then ran the test suite to confirm nothing broke. Verify: rescanned after each round of fixes to confirm the findings were closed. Stop new ones: the pipeline gate meant fixed vulnerabilities could not quietly come back and new ones could not ship.
- Supported SOC 2The pipeline and the AWS platform gave the company the controls and evidence SOC 2 asks for. Change management: every change went through the pipeline, with a record of what changed, when, and which build shipped it. Vulnerability management: scans on every build, tracked findings and documented fixes. Secure development: security testing built into the development process rather than bolted on before release. Access control: IAM roles and policies limiting who and what could reach production. Infrastructure as code: environments defined in CloudFormation, consistent and reviewable.
- Cut the cloud wasteWe audited AWS billing line by line, identified idle servers and unused SSD volumes left behind by developer-created machines, and removed them. The billing data made the case, so nothing in use was touched. With infrastructure now defined as code, untracked servers stopped appearing.
How traffic reaches the store now
- 1A developer commits code.
- 2The pipeline builds it and runs automated tests.
- 3Fortify (SAST and DAST), Mend (SCA) and SonarQube scan the build.
- 4Critical finding?: The build goes back to the developer to fix and rescan.
- 5Clean build?: It is packaged and deployed automatically to the customer instances on AWS, and the database scripts run.
- 6Every step is logged, giving SOC 2 evidence by default.
All in about 10 minutes.
The result
Technology
Technology
CI/CD: Jenkins · Azure DevOps · PowerShell · NuGet · MSTest · Git Application security: Fortify on Demand (SAST, DAST) · WhiteSource / Mend (SCA) · SonarQube Cloud: AWS EC2 · Amazon ECR · AWS Lambda · Amazon RDS · AWS IAM · CloudFormation Data: SQL · PostgreSQL
Related case studies
How Tilton went from 4 outages a day to zero and cut hosting costs in half
Read case studyHow a construction SaaS took releases off developers’ machines and cut critical cloud risks to zero
Read case studyFind out what your stack is hiding.
If your releases depend on one person, your code is years old, and nothing checks it before it reaches customers' financial data, you are carrying delivery risk, security risk and audit risk at once. Book a free audit and we will show you where to start.