<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>incident response on Deployment</title><link>https://deployment.properties/tags/incident-response/</link><description>Recent content in incident response on Deployment</description><generator>Hugo -- gohugo.io</generator><language>en-us</language><lastBuildDate>Mon, 26 Oct 2026 10:00:00 -0400</lastBuildDate><atom:link href="https://deployment.properties/tags/incident-response/index.xml" rel="self" type="application/rss+xml"/><item><title>Part 4: Security Doesn't End When You Deploy</title><link>https://deployment.properties/posts/devsecops/security-doesnt-end-when-you-deploy/</link><pubDate>Mon, 26 Oct 2026 10:00:00 -0400</pubDate><guid>https://deployment.properties/posts/devsecops/security-doesnt-end-when-you-deploy/</guid><description>&lt;p>When we deploy software to production, we expect it to work as designed. We have tests, code reviews, security controls, and other practices that help reduce the likelihood of something going wrong. But as we&amp;rsquo;ve discussed throughout this series, none of these controls can guarantee that a system will never be compromised. There are things we don&amp;rsquo;t control, such as a security issue in an external service or API, or a newly discovered zero-day vulnerability in one of the dependencies we use.&lt;/p>
&lt;p>If someone exploits a vulnerability, gains unauthorized access, or abuses legitimate functionality, would we know? And once we identify the problem, how prepared are we to investigate, contain, and recover from it?&lt;/p></description></item></channel></rss>