For a lot of software projects, the go-live day is the day when the hardest work is done. The app is live. Users can get in. And the team can finally turn to performance issues, support requests and the next release cycle.
Hopefully, the team performed rigorous source code checks before launch and those certainly have value, but they only demonstrate what the application looked like before people used it in the real world. More in-depth runtime testing and infrastructure vulnerability checks can only happen after the app is live, and this is often when exploits are revealed.
The potential breach still poses a real financial risk. A recent report from IBM found that the global average cost of a data breach last year was $4.44 million.
Of course, the exact figure will vary by sector, location, the nature of the breach and other factors, but the point is clear enough – companies need to look at application security as an ongoing task, one which hardly ends upon rollout.
In practice, an app that goes live is rarely the same a few months later. Users find ways to use it that you don’t expect. Teams add functionality. Cloud configuration is evolving. New integrations are coming. Attack patterns appear. What’s safe in testing can quietly become more risky as the product and the business around it change.
Key Takeaways
- Understanding why deployment is only one stage.
- Analyzing why live applications keep changing.
- Assessing how monitoring helps catch new problems.
- Exploring why risk prioritization prevents wasted effort.
Application security is easier to manage when it is treated as a lifecycle practice. It starts during planning and design, continues through development and testing, and remains important after deployment.
“Pre-launch checks are still important. Teams can review code, test the login and auth flows, scan for vulnerabilities, check permissions, etc. They may also examine the handling of sensitive data. These steps reduce the possibility of going live with obvious defects.
Even a careful test before launch can’t anticipate every condition after release. Application can be used by users in ways that team did not anticipate. Employees could alter settings to solve a short-term problem. A developer could add a new integration to accommodate a customer request. A third-party component may need an urgent security patch later.
Deployment should be a turning point. Then the work moves from launch preparation to ongoing protection.
Modern applications are seldom simple. You can hook a customer portal up to a payment provider, a login service, a database and some APIs. The user sees a single app. Working behind that are a number of systems.
This creates security challenges once deployed. A company could launch a portal and then later integrate it into a marketing platform. A team might add a mobile app that shares the same backend. Maybe someone changed a cloud storage setting as part of troubleshooting and forgot to close it up. That’s not abnormal. The issue is that every change could add a new entry point or weaken an existing control.
None of this is unusual. The problem is that each change can create a new entry point or weaken an existing control.
Security testing before deployment is a snapshot of the application at a point in time. The monitoring post deployment informs you what is going on while the application is being used.
Post-launch monitoring allows teams to detect suspicious behaviour sooner. Repeated failed log-ins may be a red flag. Other examples include unusual traffic patterns, unauthorised access attempts and sudden changes in exposed services. The sooner you pick up the warning signs, the more time a company has to react.
In this sense, for applications with sensitive data, it can be especially relevant to track activity and run vulnerability checks on a regular basis.
After all, not every vulnerability carries the same risk levels.
The risk is even higher if a potential exploit involves customer accounts, payment information, business files and employee credentials. If something goes wrong, the damage may be beyond the technical scope of repair. It can impact operations, trust, compliance and revenue.
Many applications rely on third-party software such as open source libraries, frameworks, plugins, and cloud services. These tools enable teams to build faster.
They also need to be tracked after release, as the attack surface changes shape.
A component could be safe at the time the app loads. A vulnerability was found later on. “When that happens, the company should know if that component is actually being used, where it shows up and if it is exposed. It also needs to know if the problem is exposed and how fast it should be fixed.
For example, in the case of public-accessible systems, patching should be part of a regular maintenance plan. Updates help prevent known vulnerabilities from being exploited. The problem is where to begin. For example, a low-risk issue on an internal test page is not as bad as an access control issue on a public customer portal.
Scan results and alerts can easily overwhelm security teams. A scan or penetration test can reveal urgent issues and things that pose little practical risk. Some are in public-facing systems, some are in areas of limited exposure.
A practical application security programme should rank issues by risk.
Severity is only one part of the decision. Teams also need to consider whether the issue is exposed, whether it can be exploited, what data it could affect, and how much damage it could cause.
For example, an exposed API that handles customer data should usually receive faster attention than a minor issue on an unused internal page. A misconfigured cloud service may also need urgent action if it is reachable from the internet.
Security teams need to focus on the issues most likely to harm the business instead of treating every finding as equally urgent.
Cloud services and APIs let teams move faster, but they can leave behind systems that are harder to track.
You can build an API for a partner, and forget about it. A test system may be continued in operation after completion of a project. A cloud service might be unintentionally exposed. Each one can be an entry point, as long as they are exposed or not configured properly. If a company doesn’t know what’s exposed, it can’t protect it.
App security teams need a clear view of which applications and APIs are reachable from outside the organization. That same visibility should extend to cloud services and domains that support the application. They also need to know who owns them, whether they are still active, and which risks need attention first.
Without that visibility, application security is reactive. A problem might be identified after an incident, a customer complaint or an external report.
Deployment does not end the responsibility to protect an application. Security becomes even more important after launch because the application is now connected to real users, real data, and real business processes.
Organisations can begin by incorporating security into routine maintenance activities, such as monitoring live systems, reviewing changes, updating software, testing exposed assets, and assigning ownership. Even a safer application receives attention after launch, making it less likely that a preventable weakness becomes an expensive incident.
Application security doesn’t stop once an app goes live, as cyber threats keep evolving everyday.
Regular updates, monitoring and security checks enable businesses to protect user data, prevent attacks and gain customer trust over time.
