10 August 2025

Insecure Software Development Lifecycle

Every so often I come across an application security-related news story that makes me shake my head at some of the practices in certain organisations. I can’t say for sure what the reason behind it is — perhaps lack of investment, awareness, missing controls, ineffective controls, laziness, etc. but the end result is the same.

Earlier this year, the education giant Pearson suffered a cyber attack which resulted in corporate data and customer information being leaked. The entrypoint seemingly came from a hardcoded secret:

…threat actors compromised Pearson’s developer environment in January 2025 through an exposed GitLab Personal Access Token (PAT) found in a public .git/config file.

In the attack on Pearson, the exposed token allowed the threat actors to access the company’s source code, which contained further hard-coded credentials and authentication tokens for cloud platforms.

Over the following months, the threat actor reportedly used these credentials to steal terabytes of data from the company’s internal network and cloud infrastructure, including AWS, Google Cloud, and various cloud-based database services such as Snowflake and Salesforce CRM.

This stolen data allegedly contains customer information, financials, support tickets, and source code, with millions of people impacted.

There was seemingly a whole trove secrets hardcoded within Pearson’s source code allowing for lateral movement from one system to another. This is in 2025 when we have a multitude of well-established and FOSS secrets scanning tools. How does a big business allow this to happen?

Interestingly, Pearson had another breach in 2018 and even paid a $1 million fine to settle charges that it misled investors about the data breach during which millions of student records were stolen.

In the same month came news of another breach. Telemessage, a firm selling modified versions of popular messaging apps to the U.S. government and used by top US officials, had hardcoded credentials stored for a WordPress API in the app’s source code and used a seven year old version of Spring Boot that exposed a vulnerable endpoint. The vulnerable default configuration for Spring Boot was only present in versions up to 1.5 from 2017. The breach resulted in a 410GB database of confidential messages being leaked online.

Having awareness of vulnerable dependencies and keeping these up-to-date — preferably in an automated way ­ is critical to application security. On top of these bad practices, one has to wonder what kind of procurement operations are being run that miss such sloppy development practices. If you are going to be using a communication tool to cover your most highly classified information, you better make sure to have independent assurance over the security of the development lifecycle. In addition to the US government, Telemessage’s other clients included Coinbase, JP Morgan, VC firm Andreessen Horowitz, and the Washington DC police force.

On top of these issues, they were using a weak password hashing algorithm without any salting or peppering (not the culinary kind). I also find it interesting that the attackers used typical enumeration techniques to find the vulnerable endpoints on the telemessage.com subdomains. How did those resources even make it to production and clear any penetration testing or dynamic application security testing? There was no reason to expose such Spring Boot Actuator endpoints in a production environment. The more attack surface you unnecessarily expose, the greater the risk the to your applications and services.

There’s no such thing as 100% security and there’s always a level of residual risk, but given where we are now with application security frameworks and the multitude of available resources, from ISO, OWASP, NIST, CWE, CSA and many other organisations sharing valuable best practices, we really should be doing much better.

References

https://www.bleepingcomputer.com/news/security/education-giant-pearson-hit-by-cyberattack-exposing-customer-data/ https://www.theregister.com/2025/08/10/telemessage_archive_online/ https://www.bleepingcomputer.com/news/security/hackers-scanning-for-telemessage-signal-clone-flaw-exposing-passwords/ https://www.labs.greynoise.io/grimoire/2025-07-16-checking-the-scope-of-cve-2025-48927/ https://www.wired.com/story/how-the-signal-knock-off-app-telemessage-got-hacked-in-20-minutes/ https://marketbrief.edweek.org/regulation-policy/pearson-will-pay-1-million-fine-for-understating-2018-data-breach-misleading-investors/2021/08 https://ddosecrets.com/article/telemessage https://micahflee.com/telemessage-explorer-a-new-open-source-research-tool/