Securing applications after a cyberattack: a recovery guide

Securing applications after a cyberattack means checking the code, tools and accounts that build your software, not just servers. This guide covers containment, pipeline recovery and safer remote work with tools like Hide Expert VPN.

Why a breach can reach your software pipeline

Traditional incident response focuses on infected machines and stolen data. Attackers who reach a development environment can do something worse: change the software you ship. If the build pipeline is compromised, every new release can carry the attacker's code – sometimes with a valid signature.

Two well-known supply chain attacks show the risk. In the SolarWinds breach, attackers inserted a backdoor into updates of a widely used IT management product, and those updates reached thousands of organizations. In 2023, installers of the 3CX desktop app were distributed with malicious code after the company's build environment was compromised. In both cases, customers trusted the software because it came from the official vendor.

Securing applications after a cyberattack: first steps

When you discover a breach, assume that anything the attacker could reach may have been altered. Work through these steps:

1. Contain affected systems. Isolate compromised endpoints, build agents and servers, but preserve logs and disk images for the investigation.
2. Scan developer endpoints. Laptops with repository access are a common entry point, so check them for malware before they reconnect.
3. Rotate every secret. Change passwords, API keys, SSH keys, access tokens and signing keys used by affected systems. Treat secrets in environment variables, CI settings and config files as exposed.
4. Revoke sessions and review access. End active sessions, remove unused accounts and confirm that each person still needs their permissions.
5. Validate code and containers. Compare source code with known-good commits, rebuild images from trusted base images and check dependencies for unexpected changes.
6. Verify release binaries. Compare hashes of current builds with those recorded before the incident, and run binary analysis on anything that doesn't match.

Signing keys deserve special care: a stolen key lets attackers make malware look genuine, and the leaked MSI signing keys showed how many products a single leak can affect.

Don't trust a compromised toolchain

Compilers, build servers, package managers and CI/CD platforms run with high privileges. If an attacker controls one of them, clean source code can still produce a malicious build. When a popular CI/CD platform disclosed a breach in early 2023, it advised customers to rotate all secrets stored on the service – a sign of how much these systems hold.

To restore trust in your toolchain:

• Reinstall build tools from verified sources instead of reusing copies that may have been altered.
• Pin dependency versions and verify checksums.
• Restrict who can change pipeline configuration and require review for those changes.
• Use short-lived build environments, so each job starts from a clean image.
• Store hashes or signatures of every release, so you can detect tampering later.

Lock down developer access

Developer accounts often lead straight to production, so they need the same attention as servers. Require two-factor authentication for developers on code hosting, CI and cloud consoles, and give each person access only to the repositories they work on.

Remote work adds another risk. Developers who connect from home or public Wi-Fi send credentials and code over networks the company doesn't control. A VPN encrypts that traffic between the device and the VPN server – Hide Expert, for example, supports WireGuard, OpenVPN and IKEv2 and has apps for all major platforms. A VPN won't remove malware from a laptop, so it complements endpoint security rather than replacing it.

Build security in from the start

Fixing a flaw during development is easier than fixing it after release. This approach, often called shifting left, means security checks run as part of everyday work rather than as a final gate. Strong application security across the whole software development lifecycle (SDLC) also limits how far an attacker can get next time.

Habits that help:

• Run static analysis and dependency scanning on every pull request.
• Block commits that contain secrets.
• Require code review for every change to protected branches.
• Use anomaly testing to flag unusual build output, file sizes or new network calls.
• Give your APIs the same scrutiny as your user interface, since API breaches often start with a single unprotected endpoint.

Restore trust with your users

Once the incident is contained, be open about it. Tell customers which versions were affected, what you changed and what they should do – for example, update to a clean release or rotate their own credentials. Security teams and developers should then review the incident together and turn the lessons into new controls.

Conclusion

No organization can rule out a breach, especially when third-party software is involved. What you can control is preparation: keep an incident plan for your pipeline, protect developer accounts and secrets, verify every build and make security part of development from day one.