<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>security mindset on Deployment</title><link>https://deployment.properties/tags/security-mindset/</link><description>Recent content in security mindset on Deployment</description><generator>Hugo -- gohugo.io</generator><language>en-us</language><lastBuildDate>Sat, 24 Oct 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://deployment.properties/tags/security-mindset/index.xml" rel="self" type="application/rss+xml"/><item><title>Part 2: A Vulnerability Is Often Just the Beginning</title><link>https://deployment.properties/posts/devsecops/a-vulnerability-is-often-just-the-beginning/</link><pubDate>Sat, 24 Oct 2026 00:00:00 +0000</pubDate><guid>https://deployment.properties/posts/devsecops/a-vulnerability-is-often-just-the-beginning/</guid><description>&lt;p>When we identify a security issue, it&amp;rsquo;s natural to focus on the bug itself: what is vulnerable, how it can be exploited, and how to fix it. These are important questions, of course, but they don&amp;rsquo;t tell us how bad the consequences could be. For that, we need to understand the application, its permissions, the data it handles, and what an attacker might be able to do after exploiting the weakness.&lt;/p>
&lt;p>That&amp;rsquo;s a useful distinction to make when assessing risk. A vulnerability can be an isolated problem with limited consequences, or it can become the starting point for a broader compromise. The same type of vulnerability can present very different levels of risk depending on the surrounding context.&lt;/p></description></item><item><title>Part 1: When Your Software Is Open to the World</title><link>https://deployment.properties/posts/devsecops/when-your-software-is-open-to-the-world/</link><pubDate>Wed, 21 Oct 2026 00:00:00 +0000</pubDate><guid>https://deployment.properties/posts/devsecops/when-your-software-is-open-to-the-world/</guid><description>&lt;p>When it comes to security, there are a lot of things I&amp;rsquo;d love to have known when I started my career as a software engineer. Now, as an engineer focused on cybersecurity, there are things I&amp;rsquo;d like my product engineering colleagues to know.&lt;/p>
&lt;p>There are books, videos, and other resources out there that can teach you about vulnerabilities, what they are, and how they can be exploited. Others teach tools and methods for scanning code, finding vulnerabilities, and fixing them. Some of these resources, usually the good ones, bring more than just technical expertise. They help develop an adversarial way of thinking, which is fundamental to understanding where weaknesses might exist, how attacks can happen, and how far they could go.&lt;/p>
&lt;p>This post is the first in a series where I want to share some habits and perspectives that can help software engineers develop a strong security mindset.&lt;/p></description></item></channel></rss>