How a US fintech went from manual laptop releases to a secure 10-minute pipeline
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 deployment. We 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 AWS. With 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 build. Once 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 them. The 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 2. The 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 waste. We 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.
The result
Releases in about 10 minutes
Down from days, with no single developer needed to build or ship a release
250+ instances, one process
Every customer instance deployed automatically and consistently.
Fully on AWS, as code
Migrated from on-premise to AWS and defined in CloudFormation.
Thousands of vulnerabilities found
Most of them fixed by our team, including upgrading vulnerable open-source libraries.
Every build security-scanned
SAST, DAST, SCA and code quality checks before anything reaches customers.
SOC 2 supported
Change management, vulnerability management, access control and secure development in place.
About $35K a month saved
On AWS, by removing idle servers and unused storage.
Services involved
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.
Book a free audit →