Safeguard on social

For thirty years software was WYSIWYG: what you see is what you get. Millions of teams ran the same release of the same package, so one advisory protected everyone at once. Coding agents break that. They pick the packages, the model, the skills and the connectors for each task, so two teams asking for the same service get different trees and different call paths. "Known good" stops being something we share. Our new post argues the unit of security becomes the build: an SBOM and AI-BOM per build, verifiable provenance, static reachability, a policy gate in CI, a package firewall in front of installs, explicit agent permission modes, and fixes that arrive as pull requests your own CI tests. WYGIWYN: what you get is what you need. https://lnkd.in/g5DMxEpG

Whether your team standardised on Anthropic's Claude or OpenAI's ChatGPT, where your code and prompts go should be your decision. In Safeguard you make both halves of that call. The model. Claude or GPT models through your own vendor account, Safeguard's own models, a self-hosted or open-weight model, or one you built behind an OpenAI-compatible, Anthropic Messages or Gemini API. An admin adds it under Integrations, Configure Scanner, Models, the key stays in the credential vault, and "Route jobs to this model" sends Safeguard's AI features, such as search and chat, to it. The deployment. Safeguard SaaS in the US, EU (Frankfurt) or Gov region, a private VPC, on-prem, or air-gapped with Safeguard's own models included. One honest note. Closed models from Anthropic, OpenAI, Google and xAI never run on-prem or air-gapped, so air-gapped means Safeguard's or open-weight models. And with Safeguard SaaS, a self-hosted endpoint has to be reachable from Safeguard. Your model, your deployment, your call. (2 of 3 in the series "Your model, your call") Where your code and data go: https://lnkd.in/gnwZMkP4 Claude is a product of Anthropic. ChatGPT is a product of OpenAI. #AppSec #SupplyChainSecurity #DataResidency #CISO

Most security tools stall after the first enthusiastic team, when the twentieth team needs access. The blockers are about identity and control, not scanning. A rollout order that works: pilot one team, put SSO, multi-factor and roles in first, run policies in Warn or Notify, then switch the gates that matter to Block. The pieces it leans on: SAML 2.0 or OpenID Connect sign-in, SCIM 2.0 deprovisioning, built-in and custom roles scoped to an organization or team, a tenant and organization hierarchy, and an append-only audit log you can stream to your SIEM. The full guide for the AppSec or platform owner running the rollout and the identity architect signing it off: https://lnkd.in/gnwzBv5A #SSO #SCIM #AppSec #DevSecOps

Writing an Agent Skill takes ten minutes. Writing one that triggers on the right requests and does not hand an attacker your shell takes real engineering. A skill is a folder with a https://lnkd.in/gZ44vq46, loaded in stages: the description first, the body when a task matches, bundled files only when the instructions call for them. That is why the parts that run are the parts nobody reads until they run. Our new guide goes field by field through the format, shows how to write and test a skill so the description triggers it, then takes apart eight risks with a control for each: trojaned scripts, injected instructions, broad allowed tools, inline shell, secrets, impersonated marketplaces, runtime installs and silent updates. https://lnkd.in/gjnyYWBk

An MCP server is code you run with your credentials. Most teams approve one and never look again. On 25 September 2025 Postmark said someone had impersonated it with an npm package called postmark-mcp. After 15 clean versions, 1.0.16 quietly blind copied every email the tool sent to an outside address. Nothing in the tool description changed, so neither the model nor the user could see it. Our new guide explains MCP at the wire level, then the lethal trifecta (private data, untrusted content and a way out), then all ten OWASP MCP Top 10 risks with a concrete fix for each, from token leaks and tool poisoning to shadow servers. It also notes the OWASP list is still in beta, so treat it as an evolving reference. https://lnkd.in/g3C4rGKk

You fixed an XXE finding by hand. Months later it is back. XXE is mostly a configuration problem, not a library version problem. A SAML handler, an SVG preview or a partner feed reader arrives with a one line parse call, and nothing tells its author about the setting the other parsers have. Our new post makes it a pull request check. It covers the parser settings for Java, .NET, Python, PHP, Go, http://Node.js and Ruby, then three CI checks: a static rule for parser construction, a negative test with a DOCTYPE fixture the parser must reject, and runtime version assertions. It also lists library versions with XXE fixes, such as lxml 6.1.0 and Nokogiri 1.19.4, and notes that some advisories have no patched version at all. https://lnkd.in/gQUdsKQm

A new blocking rule that breaks every build tends to get switched off. Roll it out in two steps instead. In Safeguard, each policy has one action: Block, Warn or Notify. Warn: the gate still passes, with a warning that names the policy. Notify: the gate passes and your channels are told. Block: the gate fails. Start the rule as a warn, watch what it matches, fix what you can, then flip the same rule to Block. A gate with any failing Block policy fails. In CI, one step connects the verdict to your pipeline: safeguard ci scan --wait --fail-on-gate . Per the docs it exits 0 when the gate is Passed or Warning, and nonzero when it is Failed, Error or Not evaluated. Warn early where a fix is cheap, block late where the decision is final. What policies, gates and guardrails each do, and where each runs: https://lnkd.in/g6TpkM9W The five points between editor and cluster where this pays off: https://lnkd.in/gpgUhFQj #DevSecOps #AppSec #SupplyChainSecurity

Audits rarely fail on the open finding. They fail on the open finding with no record. The record has to answer four questions: who decided, on what basis, when does it end, and has anything changed since. Our new post walks through Mitigations in Safeguard. Four types, each making a different claim: Risk Acceptance, False Positive, Workaround Applied and Not Applicable. Each carries a justification, an approver, optional evidence and a scope. Expiry is optional in the form, so we argue for making it mandatory in your process. Presets are 30, 90, 180 and 365 days, with reminders 14 days before, 7 days before and on the day. Once it expires, the finding counts again in gates. The History tab and the Mitigations report give you the audit trail. https://lnkd.in/g5jCFeqH

Anthropic filed a Form S-1 on 26 October 2026. If your team depends on Claude, the filing is also a source of vendor review questions. It is a preliminary prospectus, so treat it as a dated snapshot. What it gives a security team is a plain account of how a frontier model provider describes its own risks: weight theft, agent attack paths, cloud concentration, export curbs and incident duties. A sample of the 14 questions in the post: 1. Data: what is retained, for how long, where, and who can access it? 2. Supply chain: do you publish SBOMs for SDKs, CLIs and plugins, and how are releases signed? 3. Agents: what can an agent do without human approval, and how are MCP credentials scoped and revoked? 4. Availability: what notice do we get before a model is restricted or withdrawn? 5. Incidents: what is the contractual window to tell us, and will you tell us about misuse that targeted us? None of these can be answered with a link to a marketing page. Your side counts too: the filing notes that incidents can come from customer misconfiguration, so build an AI-BOM, inventory your MCP connectors and set least-privilege agent permissions. Swipe for the questions by group. Full post, with the mapping from disclosure to question: https://lnkd.in/gDyff7Bk Not investment advice. We read the filing only for what it tells a customer's security team. #AISecurity #VendorRisk #ThirdPartyRisk

Safeguard Desktop 3.3.0 is out. What is in it, from the release notes: It runs on Electron 45, so it picks up Chromium and Node security updates. Your saved sign-in is now encrypted with your computer's own key (the macOS Keychain, Windows data protection, or the Secret Service or KWallet on Linux). Nobody is signed out by the change. On Linux, the AppImage runs inside Chromium's sandbox wherever your system allows it, and it no longer needs libfuse2. The Mac builds are signed and notarized. Windows and Linux installers are on the page too, with SHA-256 checksums listed so you can verify what you download. Download it from https://lnkd.in/gvcRpjMi #AppSec #SupplyChainSecurity #DevSecOps

A licence change is a supply chain event. Redis 7.2.x and earlier are BSD 3-Clause. Redis 7.4.x to 7.8.x are RSALv2 or SSPLv1. Redis 8 and later are tri-licensed: RSALv2, SSPLv1 or AGPLv3. Redis's own licence page says SSPLv1 is not an open source licence and AGPLv3 is OSI approved. Valkey continues from Redis 7.2.4 under BSD 3-Clause. The Linux Foundation announced its intent to form it on 28 March 2024. The licence line depends on the project and the version you run. An SBOM that only says "redis" will not tell you which. Check what your SBOM says about the Redis-compatible server you run: which project, which version, which licence. Then check the same for every other component that could change terms between releases. Not legal advice. Your counsel decides what a licence requires of you. Release history, licence by version and the fork: https://lnkd.in/gpxXBbf3 Facts as of 26 Oct 2026, from https://lnkd.in/g7vFKDdr, https://lnkd.in/gucC_dU7 and https://lnkd.in/gxaZfrjf. #SBOM #Redis #Valkey #OpenSource

How does a small team fix many repositories at once? Select the vulnerabilities, run remediation on the selection, and Safeguard batches compatible fixes into one pull request per repository instead of a stream of tiny ones. You review the lot first. The point is not that nobody reads anything. It is that a small team can cover many repositories because only the exceptions need a person. The short answer: https://lnkd.in/g3p6KvhW The full episode: https://lnkd.in/guQJCN_3

Does an auto-fix run your tests first? With CI connected, Safeguard can trigger your existing tests against the proposed change before the pull request opens. If they pass, the PR opens with a passing status. If they fail, it stays open for a human, and auto-merge never goes past a failing build. One honest caveat: a fix is only as well checked as your tests are. Green means it builds and passes what you wrote. The short answer: https://lnkd.in/gRVGA4VQ The full episode: https://lnkd.in/gFebRPb4

An email lands on a Friday afternoon: send me everything you hold about me, and delete my account. The one month clock has started. What does your company have to show when someone asks how you handled it? The Audit Window, Season 1, Episode 3, "GDPR for a small SaaS: the data subject request and the evidence behind it", follows one request from the received date to the day the answer goes out: who checked identity, which systems were searched, who reviewed the package. It also covers erasure and backups, and what a record of processing is for. Listen on Spotify: https://lnkd.in/gYpfCeNh

About USD 6.3 billion left Binance on 29 October, most of it in about 20 minutes per TRM Labs. Binance says it may have started with a compromised DevOps engineer's laptop, then found "additional points of breach". On 31 October the FBI named North Korea's TraderTraitor. The full attack path is not public yet, and a post-mortem is pending. What is documented is the playbook: fake recruiters, trojanized coding tests and malicious packages aimed at developers, per CISA, GitHub and the FBI since 2022. That makes the engineer's machine the place to look first. The carousel covers what happened, what Binance and the FBI have said, and a five-point checklist for exchanges and fintechs: check packages at install time, lock dependencies and block install scripts, run coding tests in throwaway VMs, use short-lived access with security keys, and separate duties with allowlisted hot wallet destinations. Safeguard's Package Firewall blocks malicious, typosquatted and dependency-confusion packages at install time for npm and pip. Full breakdown: https://lnkd.in/g3fyPe6R

Should you auto-merge dependency fixes? Safe enough to be a setting. Not safe enough to be the default. In Safeguard a person reviews every fix by default. Auto-merge is opt in, scoped to the repositories, severities or ecosystems you pick, and it only fires after your own CI passes. A failing build leaves the pull request open. A sane rollout: keep everything review required for a few weeks, read the diffs and CI results, then promote one low risk class, like patch level bumps, to auto-merge. The short answer: https://lnkd.in/gK_Zk3ai The full episode: https://lnkd.in/guWyjSh9

Your agent is about to get a new tool. Who wrote it, and what can it touch? Gold Open Source answers the first half in a minute. Look any public MCP server up at https://lnkd.in/g3AX8bkk. It is free and needs no login. The page shows the publisher namespace, the version, whether it is a hosted endpoint or a package you install, the transport, the source repository and a license note. That tells you whose code it is and how it reaches you. A hosted endpoint is someone else's URL. An installable package is their code running on your machine, so it is a dependency: check what it depends on before you install it. What Gold does not show is the tool list or the scopes. Read those yourself in a test client with a throwaway account, then grant the least access you can. The full routine: https://lnkd.in/gYKEjKji #MCP #AIsecurity #AppSec

Safeguard is now listed among software composition analysis tools on OWASP's Component Analysis page. To be plain about it: the listing is a line in a table. The same page says OWASP does not endorse or recommend commercial products or services. The more useful part is the text above the table. It describes what component analysis covers and which risk factors matter, such as inventory, known vulnerabilities, provenance and license. Our post turns that into a test plan you can run against any SCA tool: check inventory against ground truth, trace transitive paths, export and import SBOMs, see whether VEX changes findings, and time a finding to a merged fix. The post also maps each OWASP risk factor to what Safeguard does, with links to https://lnkd.in/g8yeyeSu. https://lnkd.in/gdhHUY54

The image you are about to push. Has anything checked it yet? If your container scan runs in its own job, it probably pulls the image from a registry. That means the image was already pushed. Scan in the build job instead, right after docker build. The Safeguard CLI reads the local image on the runner and checks the OS packages, the base image and the app dependencies. Only results leave the runner. - Gate the step with a Safeguard policy gate, so a build that breaks your policy stops before your push step runs. - Push only what passed. - Scan again in the deploy job. New CVEs land after the build. Guide with copy-ready steps for five CI systems: https://lnkd.in/g_NKqNAW People footage: Mixkit stock (Mixkit Stock Video Free License). #DevSecOps #ContainerSecurity #AppSec

Five scanners usually means five inboxes. The same vulnerable library shows up in the dependency scan, again in the container scan, and a third time when static analysis flags the code that calls it. Each copy has its own ID and its own severity. Safeguard writes every engine into one findings model. AutoTriage merges duplicates from different engines into one record, and ranks what is left using CISA KEV, EPSS, static reachability and your own context. Findings it cannot decide on are treated as potentially reachable, never suppressed. Unreachable CVE findings drop to the backlog instead of disappearing. The question to ask any tool that reduces noise: what is it allowed to hide, and how can you check? The post covers ranking, ownership routing and a staged pilot. https://lnkd.in/gqZBcbn2 #AppSec #VulnerabilityManagement #SupplyChainSecurity

A vendor questionnaire tells you what a supplier said on one day. It cannot tell you that a component in their software picked up a known exploited vulnerability in June. The pattern that holds up: put every vendor in one register, tier each by how critical it is to you (Critical, High, Medium, Low), ask for SBOMs on a cadence that matches the tier, and let monitoring re-check them against new vulnerability data. Safeguard's Third Party Risk Manager scores each vendor from 0 to 100, where higher is better, and alerts on change instead of waiting for renewal season. The post walks through tiering, the SBOM request statuses and reminders, how to read the score, and how to turn renewal into a decision. It also says plainly what an SBOM does not cover. https://lnkd.in/gTdUPKuR #ThirdPartyRisk #TPRM #SBOM #SupplyChainSecurity

Self-hosted GitLab: the version number may not be the whole answer for CVE-2026-97229. GitLab scores the CI regular expression flaw CVSS 10.0 and fixed it in 19.4.2, 19.3.5 and 19.2.8 on 12 October. Ruby then shipped fixes to its Onigmo regex engine on 23 October, where the underlying bugs live. If you run GitLab's official packages or images, the GitLab version tells you most of the story. If you bring your own Ruby (source install, distro package, custom image), you also need a fixed Ruby. Alpine Linux reported an attempted exploitation of its own instance and found no evidence the attacker's code ran, though it could not rule it out. We have not seen wider confirmed exploitation. The post covers how to find your GitLab and Ruby versions on every install type, the upgrade path, CI and runner exposure, and when to rotate what. https://lnkd.in/gPwE52np #GitLab #CVE #DevSecOps #SupplyChainSecurity

Is there GPL code in this OTA image? The honest answer comes from an inventory with a license on every line, not from a memory of what the team linked. The routine, in short: 1. Build the license list from the build system, one inventory per release version. 2. Normalize to SPDX identifiers. GPL-2.0-only is not GPL-2.0-or-later, and AND is not OR. 3. Set the policy before the release: allowed, review or denied, with exceptions that name an approver and an expiry date. 4. Run it on the pull request that adds a dependency, not at the gate. 5. Keep the inventory, policy version, findings and exceptions with the release. The inventory stops where the build system stops: the vendored C library, the board support blob, the library a vendor binary links. Not legal advice. Counsel decides what a license requires of your product. Safeguard handles the SBOM, license classification and policy gates around the release; it does not scan a raw flashed binary. Full workflow in the use case post (swipe the document for the short version): https://lnkd.in/g_ZUJ-vN #OpenSourceCompliance #SBOM #Automotive

PostgreSQL 14 gets its final release on 12 November, per the project's versioning policy. After that, a bug found in code that 14 shares with newer versions gets fixed in 15 through 18 and stays open in 14. The copies that get missed are rarely the main cluster. They are the CI service container, the migration image, the reporting replica, and the database embedded in a vendor appliance. A plan for the next eleven days: 1. Inventory every PostgreSQL 14 instance, self-hosted, in containers and managed. 2. If you hold SBOMs, search them by package and version. In Safeguard that lists every project and image that carries it. Appliances show up only when the supplier gives you an SBOM. 3. Apply the final 14 release when it ships. 4. Schedule the major upgrade to 18, which the project supports until November 2030. Our write-up has the dates, the SQL to run after pg_upgrade, and a script that finds pinned PostgreSQL versions in a repo: https://lnkd.in/gdF5WtWi Footage credit: PostgresConf South Africa 2018 opening, video by Malcolm McLean, CC BY 4.0 (https://lnkd.in/g_azHTFN). Stock: Mixkit. Dates: https://lnkd.in/gD9zZyCp. #PostgreSQL #PlatformEngineering #DevOps