Safeguard on social

Your first big customer asks for a SOC 2 Type II report. If your team is under 10 people, here is the checklist. SOC 2 Type II means an independent auditor checks that your controls worked over a period of time, not just on one day. For a small team, the work comes down to eight areas: 1. Written security policies 2. Access control, with regular access reviews 3. Change management, with code review before merge 4. Vendor review 5. Vulnerability management 6. Evidence collection 7. Security training for every person 8. Incident response, as a written plan Automation helps most with evidence. In Safeguard, controls, evidence and tests sit in one place, and tests and evidence collection run on a schedule, so proof builds up while you ship instead of in a scramble before the audit window. The same automation also covers your application and supply chain security. See https://lnkd.in/gZEHux5f for current plans. Plain about the fine print: audit fees are separate, and the plan does not include the independent CPA audit. Swipe through the checklist, then see the plan: https://lnkd.in/gEc4rkAs #SOC2 #StartupSecurity #Compliance #AppSec

Jit runs open source scanners through security plans as code. Safeguard runs its own engines and opens the fix pull request. We are a competitor, so read this as a vendor's view. Jit's strengths, per the page: named scanners you can inspect and test, readable plans, and managed execution. Ours: reachability verdicts (reachable, conditionally reachable, unreachable, unknown) and auto-fix that opens policy gated pull requests. Autonomous remediation ships off, and every category starts on Manual. The post also covers when to choose Jit, when to choose Safeguard, and a two week proof of concept checklist. Facts about Jit are as of 28 October 2026 from its docs and announcements. The full comparison: https://lnkd.in/gVVsNRnb

US clocks go back this Sunday, 1 November, at 2:00 local time. The rule reaches your code through the IANA time zone database, and only when an update carries it. Release 2026e is the current one. It includes the last of four Canadian changes to permanent standard time, so older data can still move a clock back where it should not. The catch is that one host usually holds several independent copies of that data: the OS zoneinfo files, a Java runtime's own copy, Node and browser ICU, a Python tzdata package, Go's embedded data. They can disagree. A short check before the weekend: Run zdump on a few zones, per host and per runtime. Keep storage and logs in UTC. Review jobs scheduled in local time, because 1:30 happens twice. List the tzdata version in every image. A stale rule is not a CVE, so a vulnerability scanner will not flag it. An SBOM will list it, which is where Safeguard fits: scan images, repositories and SBOMs and see which ones still carry an older copy. Full walkthrough with commands: https://lnkd.in/gJXQtdZ8 #SRE #PlatformEngineering #DevOps

106 malicious npm and PyPI packages in three days. GitHub's advisory database published them between 26 and 28 October. 96 are on npm and 10 on PyPI, across 172 affected version entries. Several were pulled within minutes. Others were built to hurt: an install-time Monero miner that persists through systemd, a dependency-confusion beacon aimed at internal package scopes, and PyPI infostealers. Check your lockfiles first. The post has a script that does it, plus cleanup steps if you find a hit. Then put a control on the fetch path. Safeguard's Package Firewall sits in front of npm and pip and may block malicious, typosquatted and dependency-confusion packages before any install script runs. To be clear, the packages in this batch were found by others, not by Safeguard. What they did and how to block the next batch: https://lnkd.in/gWwJkFs9 #npm #PyPI #SupplyChainSecurity

CISA added CVE-2026-110447 to its Known Exploited Vulnerabilities catalog on 23 October. It is an unauthenticated OS command injection in the richdocumentscode proxy of the Nextcloud "Collabora Online - Built-in CODE Server" app. One crafted request runs shell commands as the web server user, and attackers have used it to drop web shells since at least 10 September. Fixed in richdocumentscode 26.4.303 (26.4.402 is the current release). Standalone Collabora Online servers are not affected, only the built-in app. The question for platform and AppSec teams: is that app in your SBOM? It is a PHP component inside a Nextcloud deployment, so an SBOM that lists only the server will not show it. If your SBOMs include installed Nextcloud apps, this is a lookup (Safeguard's SBOM lookup shows where a component and version sits across your estate). If not, that is the gap to close today. Then update, and check for web shells, because exploitation started before most people knew there was a bug. Our write-up of how the bug works and how to check a server: https://lnkd.in/gb5qMAfc Source: CISA KEV entry for CVE-2026-110447 (added 23 Oct 2026). #Nextcloud #CISAKEV #SBOM #AppSec

Before you add a dependency, look it up. A package page on https://lnkd.in/enhwZh3J is free and needs no login. It shows the version Gold indexed, the known vulnerability count for that version, a verification panel with a note on each row, and an OpenSSF Scorecard health grade with the checks behind it. Then check what a page can't tell you: - Is the indexed version the one in your pull request? - What does the license say, at the registry and in the repository? - What do the install scripts do? A zero count means nothing is publicly known about that release. It does not mean the code is clean. The full routine: https://lnkd.in/eDj8UzDB #OpenSource #AppSec #SoftwareSupplyChain

Your board does not want 4,000 findings. It wants to know if the program is getting better or worse. A CISO needs one page to watch every week and one short pack to send every month. In Safeguard the page is the Program Overview dashboard, and two tiles carry the most weight: known exploited vulnerabilities (KEV) open in production, which the docs say should read zero, and time to remediate. Read time to remediate by severity and environment, next to the exceptions list, so a quiet backlog does not pass for a fast one. Scheduled reports do the delivery: a daily digest, a Monday executive summary and a monthly board pack, each as a PDF with charts plus a JSON payload. Exports respect role based access, time travel shows posture on the day of an incident, and metrics can flow to your own stack over OpenTelemetry. What to watch weekly versus what to show the board, plus a 30 day setup plan: https://lnkd.in/ecWQVa5S #CISO #AppSec #SupplyChainSecurity #BoardReporting

Your coding agents already emit telemetry. Do you know what they did last night? OpenAI Codex and Claude Code can both export OpenTelemetry. Safeguard now receives it, so you can see what the agents actually did and work it as detections your SOC can act on. What lands in Safeguard: sessions, tool decisions and their results, model calls, tokens and cost, and sub-agent links. Detections show up in Detection & Response and in Security Operations events. Setup is short. In Integrations, open the OpenTelemetry (OTLP) card, issue an ingest token, and paste it into the [otel] block of ~/.codex/http://config.toml. Claude Code environment variables and any OpenTelemetry Collector work too. Counts start ticking up within a minute. The questions security teams ask first: - Does it keep our prompts? Not by default. If you turn content on, it is redacted and cut to 2,048 characters, and never searchable. - What about secrets? Credentials are redacted on arrival, always. - What can the token do? Send only. It cannot read anything back. - Do you need our OpenAI or Anthropic keys? No. It is OTLP over HTTP (http/protobuf or http/json), not gRPC. For the OpenAI API itself, connect your organization with an Admin key. Safeguard only sends read requests with it. New API keys, Owner grants, new service accounts, usage days well above baseline and bursts of failed sign-ins become detections too. OTLP setup guide: https://lnkd.in/gKtg8a2V OpenAI API connector: https://lnkd.in/gRsDMh8t #AISecurity #AppSec #DevSecOps

Revocation alone does not fix a CA compromise. A CA key can sign its own CRLs and OCSP responses, so an attacker holding it can make a bad certificate look good. An intermediate has to be revoked by its parent. A root has no parent, so the only real response is to remove it from every trust store. The runbook order that follows: contain the key and stop issuance, inventory by issuer and Authority Key Identifier (not just hostname), reissue under a new key, remove the old CA from trust stores, then prove with scans that nothing still chains to it. Software that ships its own CA bundle or pins a key will not pick up an operating system trust store change. Safeguard builds SBOMs of your repositories and images, so you can find those bundled CA packages and pinning libraries in each application. The full runbook: https://lnkd.in/gZ4R5u2A

The software you buy ships open source too. Atlassian's 20 October security bulletin lists 176 entries, 75 unique CVEs, and every one sits in a bundled third-party library: Apache Tomcat, Netty, Bouncy Castle and others. The bulletin counts 162 high-severity and 14 critical-severity third-party vulnerabilities. As of 26 October none of the critical CVEs is in CISA's KEV catalog. Several of the upstream CVEs went public in August (Bouncy Castle on 3 August, Netty on 19 August, Tomcat on 25 August). The fixed builds in the bulletin are dated 20 October. That is the point for AppSec and platform leads. When you buy or self-host a product, you inherit its dependencies and its patch calendar. Your scanner sees the old JAR, and the supported fix is the vendor release. Three questions for every vendor product you run: 1. What open source is bundled inside it? 2. Which version of the product are we on? 3. Which build carries the fix? If a supplier gives you an SBOM, Safeguard can import it and match its components to known vulnerabilities. Lag table, fixed versions and checks in our post: https://lnkd.in/gRQvmzdg #AppSec #SupplyChainSecurity #VulnerabilityManagement

CVE-2026-113788 lets any Lagoon user run code through the core ssh service. Every release before 2.33.2 is affected. 2.33.1 has no security fix, so treat it as vulnerable. Fixed in Lagoon 2.33.2, shipped in the lagoon-core Helm chart 1.62.2 on 25 August 2026. The attacker needs a Lagoon user account. The score is 9.4 from the GitHub CNA. Exploitation: none reported in the sources we checked. CISA's SSVC entry on 23 October recorded exploitation none, and the CVE was not in the KEV catalog as of the 26 October release. Check: the advisory says exploitation may show up in the ssh service container logs as "too many arguments". A clean log is not proof of safety. Workaround if you cannot upgrade yet: disable the ssh service in Lagoon core. The newer ssh-portal services are not affected. How Safeguard helps: its SBOM scan flags vulnerable components in your estate so you can see where you run them. What to patch and check: https://lnkd.in/gD9Vk4iB #Lagoon #CVE #Kubernetes #SupplyChainSecurity

The maintainer has not shipped a fix for the dependency you use. Waiting is a plan, but not a good one. There are two gaps. A fix exists but has not reached your builds. Or no fix exists yet. Gap one: generate an SBOM for every build, so a new advisory is a lookup, not a search. Safeguard's autonomous remediation opens tested, policy-gated pull requests to the fixed version. It ships switched off, so your team decides how much runs on its own. Gap two: we first work to get the fix accepted upstream, because a fix at the source helps everyone. If the issue is severe or upstream will not move, we build a fork, fix the vulnerability there and publish a hardened Gold build. Gold builds are held to a bar: zero exploitable critical or high CVEs, a completed license check, a public evidence page, signed provenance (SLSA Build Level 3 is the design target) and continuous monitoring. One honest limit: if the vulnerable code sits in a vendor appliance, a hosted service or an operating system you do not build, the fix still comes from that vendor. Swipe the 8 slides, then look up your top twenty dependencies on https://lnkd.in/g6VsKZEE (free, no login). Ask which packages Gold covers today before you plan around it. Full brief: https://lnkd.in/gYy8QxSP #OpenSource #SupplyChainSecurity #AppSec #SBOM

The router you forgot you own is part of your attack surface. On 23 October ASUS fixed three High rated flaws in routers on its 102 firmware series: an authentication bypass (CVE-2026-93489, CVSS v4 score 8.7) and two root command injections (CVE-2026-75775 and CVE-2026-75779). The first lets an unauthenticated user on the adjacent network forge an access ticket and act as administrator. The CVE records list an affected firmware series and no fixed version. As of 26 October none of the three is in CISA's KEV catalog, and no exploitation has been reported. So the useful question for IT and security leads is not only what ASUS shipped. It is how many of these devices you own. The branch office. Remote workers' home setups. The unit in the closet nobody has logged into since install. Three things for this week: 1. Write down every router you own and its firmware version. 2. Update the ones that are behind. 3. Keep the admin page off the internet. Full walkthrough in our post: https://lnkd.in/gvp_JqYA #VulnerabilityManagement #NetworkSecurity #CVE

Two separate exposures at Amadeus, the airline booking technology provider, surfaced in October 2026. Korean Air and Asiana say booking data leaked through unauthorized use of login credentials assigned to an Amadeus system account, in an estimated window from August 2023 to September 2026. Separately, heise online found a Spring Boot heap dump reachable without authentication, holding credentials and tokens, with passenger records searchable by last name, many on Lufthansa and Condor flights. Amadeus told heise it learned of that on 21 September and that it is fixed. No source links the two events. No affected counts are published. Neither has a CVE. Both are vendor-side identity and configuration failures that customers learn about from the vendor. Five questions to put to any booking, payroll or SaaS vendor this week: 1. Which of your system accounts can read our data, and how are their credentials issued and rotated? 2. Do non-production environments hold our real data? 3. How many days of access logs do you keep for our data? 4. After you confirm unauthorized access, how many hours until you tell us? 5. Which services expose management or debugging endpoints, and how are they restricted? On your own side, list every service that includes Spring Boot Actuator and check what it exposes. Safeguard's dependency and image scanning gives you that list across repositories and container images. Full read, with the checks: https://lnkd.in/g7pGW3hR Sources: Korean Air and Asiana statements as reported by Korean outlets on 23 Oct 2026; heise online, 13 Oct 2026. As read on 26 Oct 2026. #VendorRisk #ThirdPartyRisk #AppSec

The Fix Window, Ep 5 is live: Three days: how fast to patch a bug that is already being used. CISA's BOD 26-04 replaced one patch deadline with four facts. Is the asset exposed to the internet? Is the flaw on the KEV catalog? Can an attacker automate the exploit? Does it give partial or total control? Mira, Cal and Theo walk through forensic triage, a fast lane for exploited flaws on exposed assets, a CI gate on known exploited CVEs, and what to say to a customer who asks about your patch SLA. It ends with six things to do this week. Mira, Cal and Theo are AI voices. The script is written by the Safeguard team and checked against our published research. Listen: https://lnkd.in/gsz3zvsJ #SecurityPodcast #AppSec #VulnerabilityManagement

One mistyped package name should not be able to reach your build. Typosquatted packages bet on a tired finger. Dependency confusion bets that your installer picks the wrong source. Either way, the bad package is already in your tree before anyone looks. Safeguard's Package Firewall moves that check to install time. It runs as a proxy between your developers, your CI and the public registries for npm and pip, so every fetch is evaluated before the package reaches a laptop or a build, transitive dependencies included. It blocks malicious, typosquatted and dependency confusion packages at install time. In the video you can see the real CLI answer for a misspelled "requests": flagged as a typosquat, one edit away, and held. Rollout that works: an admin turns it on, you start the proxy locally or in CI with the Safeguard CLI, run audit mode first to see what it would stop, then move to warn and block one rule at a time with an exception path that has an owner and an expiry. Full walkthrough, with the policy table and the CLI commands: https://lnkd.in/g_NjpNtf #SupplyChainSecurity #AppSec #DevSecOps

Whether your team standardised on Anthropic's Claude or OpenAI's ChatGPT, the risk is the same: one provider, one dependency. In Safeguard you pick the model per task, and switching does not mean re-platforming. - One OpenAI-compatible endpoint. Model ids look like provider/model, so you change the id, not the integration. - Provider routes for Anthropic, OpenAI, Google, xAI, Mistral, Cohere and open-weight hosts. - The Workbench runs your own prompts through two or three candidates and shows tokens, cost, latency and time to first token for each run. - Bring your own model for Safeguard's AI features, such as search and chat, or run Zero AI: no LLM anywhere, every scanner still works. Use either, use both, or use your own. Your model, your call. Compare models: https://lnkd.in/ee4XCQmT Claude is a product of Anthropic. ChatGPT is a product of OpenAI. No endorsement implied. #AppSec #AISecurity #SupplyChainSecurity

Adobe Commerce and Magento Open Source: patch CVE-2026-48356, then check the store. It is an unrestricted file upload flaw (CWE-434), scored CVSS 3.1 9.3 Critical. Adobe's fix is in security bulletin APSB26-73. It affects Adobe Commerce, Adobe Commerce B2B, Magento Open Source and the Adobe Commerce Events module, so read the exact builds from the bulletin before you change anything. Then check, because patching does not remove what an attacker already left behind: - look in pub/media/custom_options/ for files that are not real images - search CMS blocks and pages for injected scripts - review admin users and integrations, and rotate credentials if you find anything - compare your web server config with Magento's http://nginx.conf.sample, which denies web access to /media/custom_options/ CISA added it to the KEV catalog on 27 October 2026 with a due date of 10 November 2026. How Safeguard helps: it inventories each store from its lock file, puts KEV listed findings first, and can gate the build on the fixed release. Full checklist: https://lnkd.in/eeD8PVR7

OpenSSL 3.4 lost upstream support on 22 October. OpenSSL 3.6 follows this Sunday, 1 November. After that the project maintains three lines: 3.5 LTS (to April 2030), 4.0 (to May 2027) and 4.1, released on 23 October (to November 2027). Most servers that take their distribution's updates will not notice. Ubuntu, for example, patches its own build of 3.0 and that follows Ubuntu's support. The risk is the copies nobody counted: base images that were never rebuilt, language runtimes, vendored builds. On one Mac with Homebrew OpenSSL 4 first on the PATH, the openssl command said 4.0.3 while Node reported 3.6.4. Same machine, two versions. Before 1 November: 1. List every copy of OpenSSL and its version. 2. Move what you build, bundle or install yourself to a supported line. 3.5.9 is the conservative target. An SBOM lookup covers step 1: search the SBOMs you already hold for a component and version, and see every project and image that carries it. The full guide, with a checker script for each runtime: https://lnkd.in/ep3Fazns #OpenSSL #AppSec #SBOM

Three US software security dates are coming up. 10 November 2026: CMMC Phase 2 begins. Level 2 assessments by third-party assessors can enter applicable defense contracts as a condition of award. 7 December 2026: CISA BOD 26-04 remediation timelines apply to federal agencies. Fix urgency rests on four factors: asset exposure, KEV status, exploit automation and technical impact. 1 January 2027: Colorado developer duties under its automated decision-making technology law begin. There is no single US SBOM law. Buyers ask anyway, through contracts, sector rules and board questions. Our guide takes each rule from its primary text and ends with a 90-day plan in three phases: inventory and owners in the first 30 days, rank, fix and gate in days 31 to 60, evidence and cadence in days 61 to 90. It works with any toolset. Safeguard produces the inputs: an SBOM per release, findings ranked by KEV status and reachability, supplier SBOM requests. Assessors and regulators make the decisions. Not legal advice. Full guide: https://lnkd.in/eZTc2TUM Dates as read on 26 Oct 2026 from the CMMC program rule, CISA BOD 26-04 and Colorado SB26-189. #CMMC #SBOM #AppSec #SupplyChainSecurity

One vendor breach, two universities, and a question most vendor reviews skip. On 20 October NEC said a company it outsources development and maintenance to was attacked in late September, and that valid accounts were misused against NEC customers. Osaka Metropolitan University says a further subcontractor's valid account was used to access its systems. Osaka University says files were shared on cloud storage outside the contract, and a third party downloaded them. 77,851 people are affected, duplicates removed. The notices do not name the subcontractor. What they do show is how long the chain can be: your risk includes your vendors' vendors. Can you name every company that touches your systems or your data? Which outside accounts could log in to you today, and when were they last used? Our post sets out the timeline from the official notices and the questions to send your vendors this week. If you track suppliers in Safeguard, the Third-Party Risk Manager handles vendor onboarding and ongoing risk monitoring. https://lnkd.in/gtruXqsm #ThirdPartyRisk #SupplyChainSecurity #CyberSecurity

Anthropic filed a Form S-1 with the SEC on 26 October. If your teams already run on Claude, its risk factors read like a vendor security review answered in public. What stands out for security and third-party risk teams: 1. Model weights are named as a high-value target for state-sponsored theft, and the filing says Anthropic has at times operated with "known limitations or gaps" in its defenses. 2. Agent attack paths in plain terms: poisoned external content steering an agent, hijacked sessions using a customer's own credentials, and errors that compound across multi-step workflows. 3. Dated events, including a March 2026 outage and a June 2026 export restriction that led Anthropic to disable two models for every customer until it was lifted. 4. Incidents can come from customer misconfiguration. Your side of the work: an AI-BOM, an inventory of MCP connectors and least-privilege agent permissions. We read the filing only for what it tells a customer's security team. This is not investment advice. Page references and the vendor review questions to ask: https://lnkd.in/guzrSEUt

26 of the 68 advisories on the nginx project's security advisories page were fixed in releases shipped in 2026. That is the patch cadence. The harder question is which nginx build you actually run. The upstream picture as of 26 October 2026: stable is 1.30.6 and mainline is 1.31.8. The 1.28 branch got its last release, 1.28.3, on 24 March 2026, and every advisory since 1.30.0 lists fixed versions only for 1.30 and 1.31. But if a distribution, container image or ingress controller ships your nginx, that packager sets your patch timing, and backports mean its version string may not match upstream ranges. So the useful artifact is an SBOM that records the build in every image and host. Then an advisory is a lookup, not a week of asking around. Safeguard's SBOM lookup shows where a component and version sits across your estate. Our nginx release history covers the branch model, TLS and HTTP/3, the advisory process and an upgrade checklist: https://lnkd.in/geDsS2vS Counts and versions as of 26 Oct 2026, from the nginx project's advisories and download pages. #nginx #SBOM #AppSec