Your online store, your customer portal or the platform you built a few years ago is still running. It brings in revenue, users log in every day and nobody complains. So nobody has taken a deep look at it since it went live.
The problem is that "it works" does not mean "it is secure". A platform that has been in production for years without an audit accumulates risks you cannot see from the outside: libraries with vulnerabilities discovered after they were installed, versions that no longer receive patches, access that nobody remembers granting. And attackers will not wait until you have time to look.
In this article we explain why a platform becomes insecure even when nobody touches it, which security holes show up most often, and why a 4-hour preventive audit can give you a real picture of the state of your code in production.
In short: software ages even when it is not modified. Regularly reviewing the security of your online platforms and analyzing their source code is the cheapest way to find the holes before an attacker does.
Why a platform becomes insecure without anyone touching it
It is common to think that if nobody has changed the code, the platform is as secure as the day it launched. It is not: what changes is everything around it.
- New vulnerabilities are discovered in old code. The libraries, frameworks and plugins your platform uses were safe when they were installed, but new flaws that affect existing versions are published every month. Code that was fine in 2021 may have a public vulnerability today, complete with instructions to exploit it.
- Versions stop receiving patches. All software has an expiry date. PHP, for example, gives four years of support to each version: versions 7.4, 8.0 and 8.1 no longer receive any security fixes, and 8.2 will stop receiving them on December 31, 2026. The same applies to frameworks, CMSs, databases and operating systems.
- People change, access stays. Former employees, vendors who no longer work with you or test accounts nobody deleted may still have access to the admin panel, the server or the repository.
- Attacks have been automated. Bots crawl the internet nonstop looking for platforms with known vulnerable versions. You do not need to be an interesting target: being an easy one is enough.
The data backs this up. According to Verizon's 2026 Data Breach Investigations Report, 31% of security breaches now start with the exploitation of a software vulnerability, which for the first time overtakes stolen passwords as the main way in. And companies are taking longer to fix them: the median time to fully patch a vulnerability has gone from 32 to 43 days, and only 26% of vulnerabilities known to be actively exploited end up fully fixed.
The most common security holes in unaudited platforms
When a platform has gone years without a review, these are the problems that appear most often:
- Dependencies and plugins with known vulnerabilities: outdated libraries or plugins abandoned by their authors that are still installed in production.
- Unsupported versions: of the language, the framework, the CMS or the server itself, which no longer receive security patches.
- Broken access control: users who can view or modify data that is not theirs. It is the number one risk in the OWASP Top 10:2025, the industry reference for web application security.
- Credentials in the source code: passwords, API keys or tokens written directly in the code or in the repository history, as we explain in our guide to the Git audit and the code audit.
- Insecure configuration: exposed admin panels, debug modes left on in production, error messages that reveal internal information or missing security headers.
- Forgotten accounts and access: users with administrator permissions who should no longer exist.
- Backups that have never been tested: they exist, but nobody knows whether they can be restored when needed.
None of these problems shows up when you use the platform normally. That is why years can go by without anyone detecting them.
Signs your platform needs a review now
If you recognize yourself in any of these situations, it is a good time to audit:
- You do not know when the framework, the CMS or the platform's libraries were last updated.
- The original developer or vendor is gone. If you have inherited the project, you may also be interested in our software vendor audit and second opinion.
- The platform handles personal data or payments from customers.
- Your team follows "if it works, don't touch it" and nobody dares to update anything.
- You have noticed strange behavior: unexplained traffic spikes, unknown users or sudden slowness.
Regularly reviewing security is also an obligation
Beyond being good practice, periodic review has legal backing. If your platform processes personal data, Article 32 of the General Data Protection Regulation (GDPR) requires a process for regularly testing, assessing and evaluating the effectiveness of security measures. And if a breach occurs, Article 33 requires notifying the supervisory authority, in Spain the AEPD, within 72 hours of becoming aware of it.
In other words: your company needs to be able to show that it reviews the security of its systems, not just that it considered it when they were built.
Prevent before you react
The difference between auditing beforehand and discovering the problem afterwards is huge:
| Preventive audit | After an incident | |
|---|---|---|
| Who finds the flaw | Your team or a trusted expert | An attacker, a customer or a third party |
| Timing | You decide and plan the fix | Urgent, with the platform compromised and 72 hours to notify if personal data is affected |
| Cost | Limited and predictable | Recovery, overtime, possible fines and lost sales |
| Impact on customers | None | Exposed data, service down and damaged trust |
| Reputation | Shows diligence | Can end up in the headlines |
What a 4-hour preventive audit can uncover
You do not need to start a long project to find out how your platform is doing. In a 4-hour preventive audit, a senior developer analyzes your source code and your platform in production, without interrupting its operation, and focuses on the places where the most serious risks tend to hide.
The goal is for you to see the real scope of the risks and the level of protection of your code in production. It is common for that first review to turn up security holes nobody knew existed. When it is over, you will know what is urgent, what can wait and whether your platform needs a deeper analysis.
At MiTSoftware we audit and maintain client platforms as part of our cybersecurity services for businesses and software review and consulting. If part of your platform's code has been generated with AI, we also recommend reading our guide to the technical audit of AI-generated code.
How often to review the security of an online platform
There is no single frequency, but these guidelines work for most companies:
- At least once a year, even if the platform has not changed.
- After major changes: new features, third-party integrations or server migrations.
- When inheriting a project from another vendor or team.
- Before a business milestone: an investment round, a launch or a big client asking for guarantees.
Between audits, it is advisable to keep dependencies up to date and watch the security advisories for the software you use.
Frequently asked questions about preventive security audits
If my platform works well, why audit it?
Because working does not mean being secure. Vulnerabilities do not usually affect normal operation: they are discovered when someone exploits them. A preventive audit looks for them first.
Does the audit affect my platform in production?
No. The review is done without interrupting the service and always with your authorization. If a finding requires a deeper test, it is planned with you.
What happens if a serious problem is found?
We tell you right away, with a clear explanation of the risk and how to fix it. If you need it, we can also take care of the fix.
How is it different from a full code audit?
A preventive audit is a first diagnosis focused on the most serious security risks of your platform in production. A full audit reviews the code, the repository and the architecture in depth; we explain it in our guide to the Git audit and the code audit.
How often should I repeat it?
At least once a year, and whenever the platform changes significantly or the team that maintains it changes.
Don't wait for an attacker to audit your platform for you
If your online platform has gone years without a review, the most likely situation is not that it is perfect, but that nobody has looked. Vulnerabilities pile up over time even when the code does not change, and today they are the main way in for attackers. Regularly reviewing security and analyzing the source code is how you find those holes while they are still cheap to close.
Want to know how your platform is really doing? Contact us and we will run a 4-hour preventive audit so you can see the real scope of the risks and the level of protection of your source code in production.
