https://nalar.dev/tags/cybersecurity/ Recent content in Cybersecurity on Nalar Hugo en-us Tue, 01 Sep 2026 00:00:00 +0700 https://nalar.dev/practical-threat-modeling-with-trust-boundaries/ Tue, 01 Sep 2026 00:00:00 +0700 https://nalar.dev/practical-threat-modeling-with-trust-boundaries/ <p>Threat modeling is most useful before a vulnerability becomes a patch request. It gives a team a structured way to ask how a system can be misused, which assumptions are security-sensitive, and where defenses should exist.</p> <p>A useful threat model does not need to be a large document. For many services, a one-page data-flow sketch plus a prioritized set of abuse cases is enough to improve design decisions.</p> <h2 id="begin-with-assets-and-security-goals">Begin with assets and security goals</h2> <p>Start by identifying what the system is trying to protect.</p> https://nalar.dev/prevent-ssrf-backend-services/ Tue, 01 Sep 2026 00:00:00 +0700 https://nalar.dev/prevent-ssrf-backend-services/ <p>Features that fetch a URL supplied by a user appear in webhook testers, image importers, link previewers, document converters, and integration platforms. They also create a server-side request forgery (SSRF) boundary: an attacker can try to make the backend send requests to destinations the attacker cannot reach directly.</p> <p>A secure design needs more than a blacklist of suspicious strings.</p> <h2 id="understand-the-trust-boundary">Understand the trust boundary</h2> <p>The dangerous capability is not URL parsing itself. It is allowing untrusted input to influence a network connection made with the server&rsquo;s network identity.</p> https://nalar.dev/reduce-software-supply-chain-risk-with-dependency-controls/ Tue, 01 Sep 2026 00:00:00 +0700 https://nalar.dev/reduce-software-supply-chain-risk-with-dependency-controls/ <p>Modern applications routinely execute code downloaded from package registries, container registries, build actions, and language-specific ecosystems. That convenience creates supply chain risk: an attacker does not need to compromise your source repository if they can compromise something your build trusts.</p> <p>No single control eliminates this risk. The practical approach is to reduce unnecessary trust and make dependency changes visible.</p> <h2 id="treat-dependency-resolution-as-a-security-boundary">Treat dependency resolution as a security boundary</h2> <p>A manifest may specify broad version ranges, while a lockfile records the exact dependency graph selected for a build.</p>