Dealing with vulnerabilities is an unfortunate but essential part of software development. There are high-profile examples that highlight the importance of proactive risk management, proving that responsibility for vulnerabilities doesn't stop at deployment. In this post, I explore: Why you should track vulnerabilities after deploying your software Ways to track vulnerabilities and how to keep your users and business safe Vulnerabilities are found deployment after It's a simple fact that software providers discover vulnerabilities deployment, not before. after There are 2 semantic reasons for this: If testing picks up a would-be vulnerability before deployment, the code never makes it to an environment to be a vulnerability An undetected, yet-to-be deployed vulnerability isn't really a vulnerability until it hits an environment where someone can exploit it Semantics aside, it's vital to know testing can't catch every problem in your code. Problems sneak through no matter how rigorous your internal testing, automated or otherwise, as you don't always know what to look for. For this reason, you should never rely solely on internal pre-deployment testing. If you're not tracking vulnerabilities deployment, then you're going to miss some. after You want to be the ones finding a vulnerability If you ship a vulnerability, it's best find it before someone with bad intentions. Hackers thrive on unmonitored apps and infrastructure, and not checking for vulnerabilities makes their lives easier. you Failure to check for, find, and resolve vulnerabilities can lead to: Downtime Risks to company, employee, and customer data Damage to your company's reputation and earnings You have a duty of care to your users to protect their interests. Not tracking vulnerabilities after deployment does your users a disservice, putting them and your own business interests at risk. It's not just those with ill-intent you need to worry about, either. Often, security researchers and library authors find vulnerabilities in code dependencies long after they're first deployed. With a lot of time passing before discovery, it means there's a good chance others included the vulnerabilities in their own software and possibly iterated on it. This brings us nicely to our next point. You don't want to accidentally iterate on a problem The short sprints of DevOps processes help limit the likelihood of iterating on undiscovered problems. Short sprints also make it easier to pinpoint the update that introduced a problem. If you don't track what happens after deployment, you reintroduce the risk of iterating on vulnerabilities. This can make vulnerabilities harder to find, troubleshoot, and fix before it's too late. Checking for vulnerabilities after deployment can save yourself (and others) time and stress in the future. Managing vulnerabilities Now you understand you should track vulnerabilities after deployment, let's look at . why how Here are a few proactive things you can do to help protect your interests. Patch and update your tools and infrastructure often While you're responsible for the safety of your own product, providers of the tools and infrastructure you use are fallible too. Even the biggest software and service providers, such as Microsoft, need to fix exploits. as another example, uses the . This model outlines expectations between the AWS services they offer and their customers. In a nutshell, AWS is responsible for the security the cloud, and customers are responsible for security the cloud. This means you're responsible for the security of the operating systems and software you run on AWS infrastructure. Amazon, Shared Responsibility Model of in Regardless of your provider, though, you must ensure the products you use to deliver your software are: As up-to-date as your company's policies allow Patched and hot-fixed where urgent vulnerabilities exist Still compliant with the promises you make to your customers You should regularly check service provider support and security pages for news on updates that will protect your product. Keep track of industry security news While checking the support pages of your vendors, you should also keep tabs on the latest cyber security news. The following websites report on new vulnerabilities and other cyber security concerns, alongside security management advice: The Hacker News Bleeping Computer Cybernews ZDNET Use a vulnerability scanner You can also use vulnerability scanners, which proactively check code and tools for known vulnerabilities. Example vulnerability scanners for code: Snyk GitHub Security Detectify Checkov CloudSploit Example vulnerability scanners for infrastructure: Intruder ManageEngine Vulnerability Manager Plus Beagle PortSwigger Burp Suite Amazon Inspector Conclusion In this post, I explored why you should check for vulnerabilities after deployment, and looked at some strategies to help manage that. Happy deployments! Also published here.

Alongside

Amazon

Discovery

Microsoft

Too Long; Didn't Read

Developers: Build Less. Deliver More. [Learn how]	

Why Tracking Vulnerabilities After Deployment Is Important

Too Long; Didn't Read

Companies Mentioned

Andy Corrigan

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

Why Tracking Vulnerabilities After Deployment Is Important

Too Long; Didn't Read

Companies Mentioned

Andy Corrigan

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES