Coder Legion - Recent posts tagged supplychain

Supply Chain Sense: Merging Gemini AI and Math for Smart Retail Inventory

Sat, 13 Jun 2026 05:51:18 +0000

In neighbourhood retail markets, local Kirana stores, and hyper-local fulfilment centres, inventory management isn't an administrative task—it's a high-stakes daily tightrope walk. If a shop owner over-orders fresh dairy, poultry, or vegetables, the items rot on the shelves, expiration windows slam shut, and cold-storage electricity bills quickly wipe out their slim profit margins.

Conversely, if they under-order to play it safe, modern quick-commerce delivery grids and retail distributors issue immediate algorithmic visibility penalties, dropping their store placement and instantly handing premium shelf space to competitors. Traditional inventory tracking relies entirely on static, backward-looking spreadsheets that fail the moment a real-world disruption strikes.

To solve this, I engineered Supply Chain Sense: an open-source, AI-driven inventory optimization suite that bridges the gap between unstructured real-world context and deterministic operations mathematics. By coupling classical Continuous Review Inventory Models with real-time risk contextualization powered by Google Gemini 2.5 Flash, the system translates unpredictable disruption narratives into live, mathematically precise supply chain parameters.

Here is a look at the foundational constraints that inspired this project, the technical architecture, the cross-category mathematics, and how the application works end-to-end.

The Genesis: The Small Business Inventory Paradox

When designing an inventory management system specifically for small business retailers and neighbourhood mini-marts, you quickly realize they operate on an incredibly tight rope. Unlike massive retail conglomerates with deep capital reserves, a small business manages a highly diverse product portfolio spanning everything from short-shelf-life dairy to slow-moving electronics. This diversity creates a brutal, high-stakes dual threat:

The Risk of Over-Stocking: Spoilage vs. Frozen Capital

If a merchant over-orders fresh goods or raw materials, the consequences are immediate. Items rot on shelves, expiration windows slam shut, and the compounding overhead costs of cold-storage electricity and disposal completely obliterate their slim profit margins. On the other hand, if they over-stock high-unit-cost non-perishables (like electronic accessories or cosmetics), items don't rot, but their vital working capital is frozen in dead inventory that sits on a shelf for six months. In this sector, excess inventory is an active financial drain.

The Risk of Under-Stocking: Brutal Platform Penalties

Conversely, under-ordering is equally catastrophic. Modern quick-commerce apps, digital delivery grids, and large distributors enforce strict service-level agreements. If a merchant experiences a stockout on basic items, they face brutal immediate financial penalties, sudden downgrades in platform algorithm visibility, and immediate loss of premium shelf space to competitors. Customers who encounter empty shelves don't just wait for a backorder; they migrate to another provider forever.

Four Key Design Decisions for a Real Product Mix

We started this project on a core set of principles tailored specifically to handle a realistic convenience store ledger, shaping how our AI layer reasons about risk across different product categories:

The Temporal Risk Window:
The ultimate question for fresh inventory isn't just "how much volume do we order?" but "when does our risk window close?" Demand calculation must be incredibly time-sensitive, because a 3-day miscalculation on fresh goods is catastrophic, resulting in a total inventory write-off.

Asymmetric Risk Mapping:
The engine recognizes that not all stockouts are created equal. Running out of critical daily staples (like fresh food and beverages) causes severe reputational damage and drops a store's customer retention rate instantly. In contrast, over-stocking a few extra shelf-stable household items is an acceptable, manageable holding cost. The system intentionally treats core staples with an asymmetric safety bias.

Hyper-Sensitivity to Weather & Seasonal Signals:
Fast-moving consumer goods are hyper-reactive to external environmental shifts. Sudden monsoon deluges break transportation corridors while spiking grocery demand, local cultural festivals shift consumption patterns within hours, and high summer temperature spikes require instantaneous adjustments to cold-chain logistics capacity.

The "Virtual COO" Directive:
Small business owners do not have the time to decrypt complex academic models or interpret abstract data science jargon. The core output of the engine needed to act as an automated, domain-aware Chief Operating Officer—delivering tactical, empathetic, and category-specific advice that reads like real operational guidance, rather than generic corporate-speak.

Grounding the Operations in Classic Math

To maintain absolute structural integrity, the engine completely avoids arbitrary adjustments. Every initialized constraint is directly mapped to established operations research and financial risk theory using a continuous review model framework.

Target Service Levels (SL) and the Z-Score Matrix

The Target Service Level represents the mathematical probability that a business will successfully fulfil customer orders without experiencing a stockout during a single vendor replenishment cycle. To convert this percentage into an active warehouse cushion, the code maps it onto a standard normal distribution curve using the Inverse Cumulative Distribution Function (also known as the Percent Point Function or Z-score function):

Z = PPF(SL)

The application initializes distinct service levels based on the financial and reputational cost of a stockout:

Food and Beverages (99% Service Level, Z approx. 2.33): High protection threshold. If an essential grocery staple is unavailable, customers migrate immediately, inducing harsh penalties.

Electronic Accessories / Home & Lifestyle (85% Service Level, Z approx. 1.04):
Lower protection threshold. These high-value, slow-moving items tie up too much capital if over-stocked, and consumers are typically willing to tolerate minor backorder wait times.

Annual Carrying Cost Rates (I) and Daily Holding Costs (H)

Storing items involves overhead (rent, climate control, insurance, and spoilage). The Annual Carrying Cost Rate (I) represents this physical expense as a percentage of the item's unit price. The engine derives the Daily Holding Cost (H) per item using the following calculation:

H = (Unit Price x I) / 365

The category rates directly correspond to product characteristics:

Food and Beverages (35% Carrying Rate): High rate driven by extreme perishability, tight shelf-life limitations, and the steep energy costs required for refrigerated storage.

Fashion Accessories (25% Carrying Rate): High rate driven by rapid style obsolescence and seasonal demand expiration.

Electronic Accessories (15% Carrying Rate): Low rate due to high material stability, compact shelf volume, and long physical shelf-life profiles.

Elevating the Square Root of Lead Time

The Core Mathematics: Why Variance Scales with sqrt(Lead Time)

A common mistake in basic inventory systems is multiplying demand volatility (std_dev) linearly by the supplier lead time duration. Supply Chain Sense strictly avoids this by implementing standard statistical operations theory: standard deviation does not scale linearly over time; variance does.

Because daily customer demand behaves like an independent random variable, demand variance aggregates linearly across successive days (Var = std_dev^2 x Lead Time). To return this back into the physical unit dimension of a standard deviation cushion, we must extract the square root of the temporal window:

Adjusted Volatility Buffer = std_dev x sqrt(Lead Time adjusted)

This mathematical choice is critical for risk exposure. If a supply chain transit window stretches from 2 days to 8 days (a 4x increase in delay), the actual risk exposure and required safety stock cushion do not quadruple—they double (2x). Utilizing a linear multiplier would cause small businesses to massively over-order, locking up thousands of dollars of vital working capital in redundant safety stock.

System Architecture & Fail-Safe Design

To ensure true production-grade resilience for small businesses, the application handles data extraction and API calling defensively through two distinct mechanisms:

Deterministic Edge-Computed Heuristic Fallback: In real-world retail environments, you cannot assume 100% cloud uptime. If a neighborhood merchant is facing a severe regional crisis—like a monsoon or a transport strike—cellular networks often experience heavy traffic spikes or blackouts. If our software relied entirely on a stable cloud connection to reach Google Gemini, a network drop would completely freeze the store's inventory pipeline.

To prevent this single point of failure, the architecture includes a deterministic backup engine that executes completely offline on the edge, instantly parsing text logs using keyword tracking and lookahead loops if the cloud API becomes unreachable.

def intelligent_local_fallback(text_input, unique_categories):
    """
    Edge-computed deterministic backup engine to handle cloud network traffic spikes.
    """
    text = text_input.lower()
    detected_delay = 0
    words = text.split()
    
    # Extract temporal delay window from unstructured text
    for i, word in enumerate(words):
        if word in ['day', 'days', '-day'] and i > 0:
            clean_num = words[i-1].replace('-', '').strip()
            if clean_num.isdigit():
                detected_delay = int(clean_num)
                break

    # Default baseline delay handling for critical supply disruptions
    if detected_delay == 0 and any(k in text for k in ['strike', 'block', 'flood', 'storm', 'delay', 'cyclone']):
        detected_delay = 3

    food_shock = 1.00
    others_shock = 1.00
    
    # Asymmetric risk classification based on macro events
    if any(k in text for k in ['strike', 'block', 'protest', 'highway']):
        food_shock = 1.15
    elif any(k in text for k in ['cyclone', 'flood', 'storm', 'monsoon', 'weather']):
        food_shock = 1.60
        others_shock = 0.40
    elif any(k in text for k in ['holiday', 'festival', 'celebration', 'christmas']):
        food_shock = 1.30
        others_shock = 1.10

    adjustments = {}
    for cat in unique_categories:
        if any(f_word in cat.lower() for f_word in ['food', 'beverage', 'grocery', 'fresh', 'eat']):
            adjustments[cat] = { "Demand_Shock_Factor": food_shock, "Lead_Time_Delay_Days": detected_delay }
        else:
            adjustments[cat] = { "Demand_Shock_Factor": others_shock, "Lead_Time_Delay_Days": detected_delay }

    return {
        "disruption_summary": f"Local Fail-Safe Active: Inferred operational shifts with an estimated +{detected_delay} day transit bottleneck.",
        "department_adjustments": adjustments
    }

Let's break down exactly how this fallback engine isolates critical data points without an external AI model:

Text Tokenization & Temporal Search: The code normalizes the user's input with .lower() and splits it into individual words. It then searches for anchor terms like ['day', 'days', '-day']. When found, it utilizes a relative index lookahead (words[i-1]) to extract the preceding character, strips out hyphens, and runs .isdigit() to safely convert natural language mentions of transit timelines (e.g., "5-day delay") into an integer.

Keyword Risk Mapping: If no explicit day count is found but critical disruption keywords (like strike, flood, or cyclone) are present, the algorithm applies a defensive baseline delay of 3 days to keep safety parameters conservative.

Hardcoded Asymmetric Shocks: The function mimics our primary Gemini AI layer by applying uneven demand modifiers based on the crisis profile. For instance, if weather keywords like monsoon or flood are detected, it applies an aggressive 1.60 demand acceleration factor to essential groceries (food_shock) due to panic buying patterns, while deliberately dialing down discretionary categories to 0.40 (others_shock) to preserve store capital.

Schema Matching: Finally, it iterates through the active store channels and structures its return payload as a dictionary that precisely mimics the JSON schema generated by Gemini. This allows the core pandas continuous review loop to ingest the data seamlessly without knowing whether the parameters came from the cloud or the local edge.

Schema-Enforced Structural Reliability: By forcing the model configuration parameters to return exact, structured JSON maps (response_mime_type="application/json"), the system bypasses unpredictable conversational AI filler text, mapping narrative updates straight into pandas data manipulation streams without any risk of execution structural runtime crashes.

Real-World Simulation: Asymmetric Trade-Offs in Action
Let's evaluate how the system handles an intense multi-channel crisis scenario. Imagine an operator inputs the following unstructured update into the live feed:

"Heavy storms and flash floods have blocked major highway entry points, delaying incoming cargo trucks by roughly 5 days. Local news is predicting intense panic buying on household groceries, while clothing and luxury retail spots expect massive drops in foot traffic."

The platform routes this alert to the cloud, executes the optimization models, and produces asymmetric parameter overrides:

Case A: The High-Risk Channel (Food & Beverages)

AI Extraction: Gemini reads the text and extracts a Demand_Shock_Factor of 1.5 (50% velocity acceleration) and a Lead_Time_Delay_Days of +5.

The Mathematics: Total lead time expands from 2 days to 7 days. Simultaneously, average daily consumption (avg_demand) and standard deviation (std_dev) are scaled up by 1.5x to reflect panic-buying. Because consumption velocity and transit delays escalate together, the mathematical engine drives the Optimized Reorder Point upward significantly. This immediate surge creates a massive inventory buffer, keeping essential items on shelves throughout the storm and avoiding platform penalties.

Fig 1: The High-Risk Channel (Food & Beverages)

Case B: The Low-Risk Channel (Electronic Accessories or Fashion)

AI Extraction: Gemini recognizes that discretionary segments will experience a steep decline in foot traffic as consumers focus purely on survival essentials, assigning a compressed Demand_Shock_Factor of 0.5.

The Mathematics: Even though the regional transit delay pushes the supplier lead time window to 7 days, consumer buying activity drops by half. The engine balances these opposing metrics and drops the Optimized Reorder Point down safely.

Fig 2: The Low-Risk Channel (Electronic Accessories or Fashion)

The Strategic Value

This defensive suppression is where the system shines. By scaling down ordering triggers for durable, discretionary goods, the application safeguards the merchant's working capital. The money saved by not ordering slow-moving items is automatically redirected to finance the critical safety stock required for high-demand groceries.

The system then delivers customized "Virtual COO" textual guidance, explaining the exact logic of these changes in clear, operational terms before generating a downloadable blueprint (.CSV) that can be fed directly into automated procurement software.

Fig 3: Downloadable Tailored Inventory Blueprint (.csv) available after analysis

Enterprise-Grade Security: Simple Cloud Key Management

When deploying an open-source data application to public repositories like GitHub, security is a paramount concern. Hardcoding API keys or committing credential files (.env, .json) directly into a repository is an immediate security vulnerability that invites token theft and exploitation.

However, forcing small business owners to set up complex local environment variables manually defeats the purpose of building a lean, accessible application. To solve this, the architecture abstracts credential handling completely away from the source code, deploying an encrypted, cloud-native runtime boundary check that integrates seamlessly with hosted environment secret managers.

if "GEMINI_API_KEY" in st.secrets:
    os.environ["GEMINI_API_KEY"] = st.secrets["GEMINI_API_KEY"]
    try:
        client = genai.Client()
    except Exception as e:
        st.error(f"Failed to initialize Gemini Client: {e}")
else:
    st.error("**Security Token Missing!** Please add your `GEMINI_API_KEY` to your Streamlit Advanced Secrets panel.")
    st.stop()

Encrypted Sandbox Introspection: The application uses Streamlit's native dictionary abstraction, st.secrets, to check for the presence of the authentication token in the cloud's secure memory space. This completely removes the need to track, store, or manage sensitive string files within your Git tree.

Environment Variable Synchronization: Once identified, the token is bound directly into the operating system's local memory environment using os.environ["GEMINI_API_KEY"]. This ensures the downstream Google GenAI SDK can implicitly fetch the credential without requiring explicit, plain-text string handling inside individual function parameters.

Defensive Try-Except Wrapping: The instantiation call genai.Client() is safely wrapped inside an execution monitoring block. If a network configuration issue, invalid credential structure, or handshake error occurs, the system catches the failure gracefully with except Exception as e and prints a clean user-facing error message without causing a total application crash.

Assertive Streamlit Halting: If the secret token is missing entirely from the cloud environment, the code displays a clear markdown warning message and immediately invokes st.stop(). This acts as an assertive architectural boundary, completely freezing execution to prevent the optimization engine from crashing or attempting unauthorized operations further down the line.

Conclusion: Grounding Agri-Retail in Real-World Context

By anchoring the natural language comprehension of Large Language Models directly within rigorous statistical inventory control equations, we can build applications that are highly intuitive yet mathematically sound. Supply Chain Sense demonstrates its true value when dropped into highly volatile, localized ecosystems like the Indian Agri-retail corridor.

In a sector where a sudden monsoon deluge halts transport logistics overnight, local wholesale mandis face sudden price shocks, and regional festivals cause hyper-local spikes in demand for dairy and perishables within hours, static software fails.

Generative AI serves as a real-time logical reasoning layer that reads unstructured news alerts, interprets local environmental context, and immediately updates physical warehouse thresholds.

This architecture proves that AI's greatest utility isn't generating open-ended conversational filler, but acting as a dynamic data-engineering bridge—shielding small merchants from stockouts, eliminating food spoilage, and protecting thin margins in an unpredictable world.

The full repository is completely open-source, features a seamless downloadable blueprint generator for automated purchasing setups, and is ready for use.

Check out the code and deploy it for your business here: github.com/Ishaa2004
Let's connect on LinkedIn: linkedin.com/in/isha-gupta12Open to freelance projects: Need a custom dashboard, inventory model, or data pipeline for your business? I take on select freelance projects. [View my gigs on Fiverr][3] or reach out directly on LinkedIn.

https://www.fiverr.com/ishagupta102

Lazy SRE's guide to secure systems, part 2: the actions you didn't pin

Sun, 07 Jun 2026 21:55:44 +0000

Originally published at harshit.cloud on 2026-04-12.

Last March, someone with write access to the trivy-action repo rewrote 76 of its 77 version tags in place. The tags still resolved to aquasecurity/trivy-action — they just resolved to different commits than they did the week before. Every pipeline that ran aquasecurity/trivy-action@0.20.0 (and every other tagged version) ran the attacker's commit instead. Secrets exfiltrated. The stolen credentials chained into PyPI and took down LiteLLM. Nobody noticed for hours, because the workflow file diff was still clean.

This is part 2. Part 1 covered npm: the dependencies you didn't read. Part 2 is the same problem one level up: the workflows you didn't pin. Part 3 is the unsexy list — Tailscale, PrivateLink, IAP, the PAT you forgot.

The thesis from Part 1 stands. The best security work for a small team is the work Future You at 3am will actually execute. The configuration that makes the wrong thing impossible beats the runbook that only discourages it. With GitHub Actions, "the wrong thing" has gotten very specific over the last twelve months, and the configs to block each variety have gotten correspondingly precise.

pinning is necessary but not sufficient

The first thing the trivy-action incident proves: hash-pinning to @0.20.0 is not pinning. It's a name lookup. The owner of the repo is allowed to rewrite that name. The pin you actually wanted was:

- uses: aquasecurity/trivy-action@9b9a3f5c8a5c7e1b6e4d2f1c9b8a7e6d5c4b3a2f # v0.20.0

Full forty-character SHA. Immutable. The version comment is so the next reader knows what they're looking at; the SHA is so the workflow runs the code you reviewed.

Two GitHub features shipped in 2025 that change the math:

SHA pinning enforcement (Aug 2025). An org-level policy that fails workflow runs using unpinned actions, instead of warning about them. Settings → Actions → General → Action pinning. Turn it on. There is no "we'll get to it" version of this toggle.
Immutable Releases (Oct 2025, GA). Action authors opt in to making release tags non-rewritable after publication. If you publish actions, turn this on for downstream consumers. If you consume actions, prefer ones that have.

The lazy stance: enforcement at the org level. The workflow that doesn't have a forty-character SHA fails the run. The PR can't merge. The work of remembering to pin moves from every engineer's head to one setting.

What this doesn't catch: an attacker who compromises the maintainer account and ships a new tag at a new SHA. The SHA is real. Pinning by SHA doesn't help, because the workflow author will rev to the new version when they read the maintainer's release notes. Which is the next config.

cooldown is the same trick that worked for npm

Part 1's load-bearing config was SAFE_CHAIN_MINIMUM_PACKAGE_AGE_HOURS=48. The principle: most published malware is detected and pulled within hours. If you can wait, the wait does the work for you.

The action ecosystem has the same property, with a longer window. yossarian's analysis puts the cooldown that catches most supply-chain attacks at 7-14 days. So:

pinact --min-age 7 .github/workflows/*.yml

Refuses to write a pin younger than seven days. Add to pre-commit, your CI lint, or whatever your dependabot equivalent runs before opening the bump PR.

For Renovate users, the equivalent lives in the action manager:

{
  "packageRules": [
    { "matchManagers": ["github-actions"], "minimumReleaseAge": "7 days" }
  ]
}

That's it. Same trick, different ecosystem.

Fig. 2 — the wait is doing the work. Seven days closes most of the door; fourteen closes most of the rest.

The empirical question is whether seven days is enough. The trivy-action force-push was detected at about nine — seven would have caught most consumers, not all of them. The cost of fourteen is "your action versions lag upstream by two weeks." If your action surface is small (most teams are running actions/checkout, actions/setup-node, one cloud-login action, maybe a deploy action), set fourteen and forget.

pull_request_target is the new postinstall

Part 1 named postinstall as the single trigger that does the most damage and the single switch (ignore-scripts=true) that closes the most doors. Actions has the same shape and the same fix.

pull_request_target runs in the context of the base repository, with access to repository secrets, but is triggered by a PR from a fork. The legitimate use case is small: comment on PRs, label them, run lightweight metadata jobs. The illegitimate use case is enormous: check out the fork's code and execute it. The attack writes itself. Open a fork, modify a script the trusted workflow runs, watch the runner exfiltrate every secret in the env.

Astral, who maintain uv and ruff, wrote it cleanly: "these triggers are almost impossible to use securely." GitHub partially mitigated this in November 2025 by forcing pull_request_target to always use the default branch's version of the workflow, so an attacker can't push a vulnerable workflow on a feature branch and trigger it. But the foot-cannon still ships loaded if your default-branch workflow checks out PR-head code.

Fig. 3 — same workflow, different trigger, opposite blast radius.

The lazy stance:

Don't use pull_request_target unless you've named the specific reason and one other person has signed off.
If you do, never actions/checkout the PR head from inside it. Check out the base SHA, do the metadata thing, exit.
For everything else, use pull_request. It runs without secrets. Attacker-controlled code stays attacker-jailed.

Same shape as ignore-scripts=true. The setting that closes the class.

the safe defaults that go in every workflow

The four-line workflow header that does the most work per character:

permissions:
  contents: read

defaults:
  run:
    shell: bash -euo pipefail {0}

contents: read overrides the org-level default. If a step needs to push a tag or open a PR, that job opts back up to contents: write explicitly. The default is the safe one.

At the checkout step:

- uses: actions/checkout@<sha> # v4.2.0
  with:
    persist-credentials: false

The default behavior of actions/checkout is to leave a credential sitting in .git/config for the rest of the workflow. Later steps have shipped this credential into uploaded artifacts more than once. Opt out unless a later step in the same job needs to push.

Three secret-access rules with the same flavor:

Step-scoped env:, never workflow-scoped, for any secret.
Never ${{ toJson(secrets) }}. Exposes every secret in the project to the runner. There is no use case.
Never secrets: inherit on reusable workflows. Pass each secret by name. The reusable workflow gets exactly what it asked for.

The trivy-action exfiltration worked partly because secrets were workflow-scoped. The malicious step inherited every credential in the env, not just the one the legitimate scan needed. Step-scoping wouldn't have prevented the credential theft — but it would have bounded the blast radius to one secret instead of all of them.

OIDC, the promise from part 1

Part 1 ended on "the next-tier defenses are real, Part 3 names them." OIDC is the part of that conversation that lives here.

The trade: instead of storing an AWS_ACCESS_KEY_ID in repo secrets and praying nobody exfiltrates it, you configure AWS to trust GitHub's OIDC issuer for a specific repo, branch, and workflow. GitHub mints a short-lived (five-minute) OIDC identity token for the workflow run. The workflow trades that for STS credentials whose lifetime you set (default one hour). Nothing long-lived ever sits in the env.

permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: aws-actions/configure-aws-credentials@<sha> # v4.0.2
        with:
          role-to-assume: arn:aws:iam::123456789012:role/github-deploy
          aws-region: us-east-1
      - run: aws s3 sync ./dist s3://my-bucket

The role's trust policy restricts the OIDC subject to your exact repo and (ideally) branch. An attacker who compromises a fork PR can't assume the role, because they don't match the trust condition. The OIDC JWT itself lasts five minutes and the STS credential is scoped to whatever you configure (default one hour). Even an exfiltrated credential gets the attacker a bounded window of scoped access, not a permanent IAM user.

For Google Cloud, the equivalent is Workload Identity Federation. For HashiCorp Vault, the JWT auth backend. Same shape across providers.

The labor here is genuinely one-time. Configure the trust relationship once per repo, delete the long-lived key, forget about rotation forever. The rotation runbook you're not maintaining is one of the better quiet wins in this post.

zizmor is the local proxy for workflows

Part 1's safe-chain sat in front of every package install and refused malware before bytes hit disk. The action ecosystem's equivalent is zizmor — a workflow linter that reads your YAML and catches the patterns this post is about, before they merge.

brew install zizmor
zizmor .github/workflows/

It catches unpinned actions, pull_request_target with PR-head checkouts, template-injection patterns where attacker-controlled input lands in a run: string, jobs with excessive permissions. Add it to pre-commit:

# .pre-commit-config.yaml
- repo: https://github.com/woodruffw/zizmor-pre-commit
  rev: v1.x  # pin the rev, obviously
  hooks:
    - id: zizmor

The principle is identical to safe-chain. Move the security check from "after the incident, in the postmortem" to "before the PR can merge, on the dev machine." The CI run is the second line of defense. The pre-commit is the first.

the receipts

The above stack is approximately one afternoon: org-level SHA pinning enforcement, pinact --min-age 7 or Renovate minimumReleaseAge: 7 days, the four-line workflow header, persist-credentials: false, no pull_request_target with PR-head checkouts, OIDC for every cloud credential, zizmor in pre-commit.

It will not catch a maintainer-account compromise that ships clean-looking code which activates weeks later. It will not catch a determined attacker who studies your build and writes a payload that survives every linter and looks innocent at PR review. Nothing in this post will. Part 3 will name the controls that buy partial mitigation against that class: sigstore, npm provenance, reproducible builds, attested deployments. And the ones that exist to make the postmortem readable, not to prevent the incident.

For a small team, the delta from this post is moving from "we're one tag-rewrite away from a credential theft cascade" to "an attacker would need a credentialed insider, or a fifteen-minute window of luck against a scoped IAM role." That's the only delta that matters at this scale.

If you do one thing this week, turn on SHA pinning enforcement at the org level. Everything else gates off that.

Lazy SRE's guide to secure systems, part 1: the dependencies you didn't read

Sun, 07 Jun 2026 21:55:28 +0000

Originally published at harshit.cloud on 2026-04-05.

A few months ago a friend's CI pipeline tried to install a package none of us had heard of. The build failed. The error wasn't a missing dep. The error was a local proxy saying this is malware, I'm not letting it touch disk. The package was a transitive dependency, six levels deep, that had been published to npm 38 minutes earlier. Nobody on the team had asked for it.

I do platform work at a startup. The job is: keep production up, keep the bill down, keep the kind of person who reads HN comments from getting a free shell on the cluster. The thesis for the series is short. The best security work for a small team is the work Future You at 3am will actually execute. The lazy answer is also, almost always, the right one: the configuration that makes the wrong thing impossible, rather than only discouraged. This is part 1. Part 2 is GitHub (tj-actions, OIDC, fork PRs). Part 3 is the unsexy list (IAP, Tailscale, PrivateLink, Okta, default helm creds, the PAT you forgot).

the picture

You opened your editor, ran npm install, and onboarded somewhere between 800 and 2,000 packages maintained by people you have never audited. Your team reviewed five direct dependencies. The other 1,995 came in for the ride.

The job is not to read all 1,995. The job is to make sure that when one of them is the problem, the blast radius is small and the alarm goes off.

chainjacking

Chainjacking is the umbrella term for "someone got control of a package you depend on and pushed a bad version." The attacker doesn't break npm. They get the credentials of the human who publishes the package, ship a patch version, and semver puts it on your machine the next time anyone runs npm install. event-stream (2018), ua-parser-js / coa / rc (2021), lottie-player (2024), and the shai-hulud worm (Sept 2025, with a 2.0 wave in Nov 2025) that self-replicated by stealing tokens from compromised maintainer machines via TruffleHog-style secret scans and then republishing every other package that maintainer owned. The economics still work for the attacker. It is going to keep happening.

Fig. 2 — twenty-four hours from maintainer phish to credential resale. Nobody noticed the version bump.

What matters in that timeline is that the human steps are slow and the automated steps are fast. The window between "malicious version published" and "your CI runs npm install" is whatever your dependabot cron is. If you auto-merge minor and patch bumps, that window is ninety seconds.

dependency confusion

You have a private package called internal-utils. Your CI is configured with both your private registry and the public npm registry. Somebody publishes internal-utils to public npm at a higher version. CI installs the public one. Birsan did this against Apple, Microsoft, Tesla, and PayPal in a weekend in 2021 for bug bounties.

Fix, in .npmrc:

@yourorg:registry=https://npm.yourorg.internal
registry=https://registry.npmjs.org/

Scope everything internal. Register your scope on public npm as a parked placeholder. It costs nothing.

postinstall

Most install-time npm supply-chain incidents I have read the postmortem on shipped their malicious code in a postinstall script — not in runtime code. (Some recent ones, like the chalk/debug compromise of Sept 2025, activate at runtime in the browser or on first import; the switch below doesn't help against those. It does help against the install-time class, which is still the majority.) The install hook runs before your tests, before your linter, as part of the install. Default is enabled. The one-line change with the highest blast-radius reduction:

# .npmrc
ignore-scripts=true

You'll need to allowlist two to five packages that genuinely need it (typically bcrypt-shaped things). That number is small. The alternative is letting every package run code on install. Pick.

the install that buys the most

Aikido's safe-chain is an open-source local proxy that sits in front of npm, npx, yarn, pnpm, pnpx, bun, pip, uv, poetry, pipx. Every package download is intercepted and checked against Aikido Intel, an open malware feed. Malware is blocked before bytes hit disk. Which is before postinstall runs. Free. No account.

Fig. 3 — safe-chain in one picture. A local proxy in front of every package manager, checked against an open threat-intel feed.

On a dev machine:

curl -fsSL https://github.com/AikidoSec/safe-chain/releases/latest/download/install-safe-chain.sh | sh
# restart your shell
npm safe-chain-verify
# expected: OK: Safe-chain works!

In CI:

- name: Install safe-chain
  run: |
    curl -fsSL https://github.com/AikidoSec/safe-chain/releases/latest/download/install-safe-chain.sh \
      | sh -s -- --install-dir /usr/local/.safe-chain
    echo "$HOME/.safe-chain/bin" >> "$GITHUB_PATH"
- run: npm ci

And, the part that quietly does the most work — refuse to install anything younger than 48 hours, because that's the window in which most npm malware is caught and removed:

export SAFE_CHAIN_MINIMUM_PACKAGE_AGE_HOURS=48

the receipts

The above stack is approximately one afternoon of work: npm ci from a committed lockfile, ignore-scripts=true with a tiny allowlist, scoped private packages with locked registry resolution, safe-chain in front of every install, minimum package age of 48 hours. It will catch most known-bad packages, kill dependency-confusion at the registry level, and reduce postinstall blast radius to zero for the long tail. It will not catch a maintainer-account compromise that ships clean-looking malware that only activates in production weeks later. Nothing in this post will. The next-tier defenses (sigstore signing, npm provenance, reproducible builds) are real, and Part 3 will name them.

For a startup the delta from this post is moving from "one of the next ten incidents has a non-trivial chance of being yours" to "you would have to be very unlucky." That's the only delta that matters.

If you do one thing this week, go register your npm scope.

diagrams: what i tried

Three diagrams, three different tools, one brief: "explain a supply-chain attack to a tired SRE in one image." Prompts kept short. Results below.

1 — the napkin contrast (coleam00 excalidraw-diagram skill)

Brief: "two-panel hand-drawn napkin. Left panel 'what i installed': five direct deps off a 'your app' box. Right panel 'what npm install pulled in': same five direct deps, transitive sprawl under each, one of them is a red evil-helper@1.2.3, callout reads 'shipping crypto miners.'"

Result: Fig. 1. Built with the excalidraw-diagram skill, a Claude Code skill that enforces a design methodology (depth assessment → pattern mapping → evidence artifacts → mandatory render-and-validate loop) and ships a Playwright-based renderer. The .excalidraw source is downloadable; open it on excalidraw.com to edit.

Two things the skill produced that I wouldn't have prompted for: a semantic color palette (Start/Trigger orange for "your app", Error red for the malicious package, Inactive blue-dashed for the "+N more" bags), and a summary-flow strip at the bottom (5 direct → 1,200 transitive → 1 malicious → full keychain) that compresses the post's thesis into nine words. The methodology turns a drawing into an argument.

One install gotcha worth knowing: the skill loads Excalidraw via ESM and the default CDN (esm.sh) was unreachable from my environment. One-line patch in render_template.html to use cdn.jsdelivr.net and it worked.

Verdict: won for the hero. The Excalidraw aesthetic earns a place when a post needs a punchline; the skill's methodology adds the second zoom level that elevates a punchline into something that teaches.

2 — the chainjacking timeline (diagram-design, polished editorial)

Brief: "Horizontal six-stage timeline. Dark navy #11141c ground, coral #ff6b5a for the two 'compromise' stages, muted cyan #5bc0d9 for the four 'victim' stages. Each stage: small timestamp label (T-7d, T-0, T+12m, T+12m02s, T+1h, T+24h), a node on the line, a short title, one-line caption. Title 'a chainjacking attack, in six steps' (lowercase). Italic figcaption. Magazine-infographic feel, no neon, no scanlines."

Result: Fig. 2. Built by a diagram-design subagent. Came back with a ghosted "COMPROMISE / VICTIM" phase label in the background that I hadn't asked for and now wouldn't part with.

Verdict: won for explaining attacker workflow. Editorial polish without being a dashboard. The agent's improvisation (the phase label) was the part I would not have prompted my way to.

3 — the safe-chain flow (diagram-design, five-column system diagram)

Brief: "Five columns left to right: developer terminal running npm install lodash-utils, shell alias intercepting, local proxy as the focal column, Aikido Intel cloud with a lookup arrow, outcome column with a green 'installed' branch and a red 'install aborted' branch. Dark editorial background #0d1117. Cyan normal flow, red blocked, green allowed. Legend strip at the bottom."

Result: Fig. 3. Same skill as #2. Came back with harshit.cloud · lazy security baked into the footer (also unprompted, also welcome) and a clean two-outcome fork that makes the block/allow decision the visual sink.

Verdict: won for explaining a system. When the diagram has to show what a tool does, this format beats the napkin every time. The napkin is a punchline. This one is a reference.

I did not ship an animated .gif for Part 1. The infographic-gif skill is the right tool for quantitative motion — a funnel decaying, a bar chart counting up. Nothing in Part 1 needed motion to make the point. If Part 3 ends up wanting a "blast radius over 24 hours" visualisation, that's where the GIF goes.

LibKill v0.1.5

Tue, 26 May 2026 07:27:27 +0000

The past 60 days have been brutal for supply chain security:

• 639 malicious versions across 323 packages in ONE hour (AntV wave)
• A worm with valid SLSA Build Level 3 provenance (TanStack)
• North Korean APTs injecting malware into "AI-assisted coding" workflows
• Credential stealers hiding in node-ipc, axios, lightning, and hundreds more
I built LibKill to answer one question: "Is my system clean?"
It scans your npm/pip packages against 2,800+ known compromised artifacts and tells you exactly what to remove. No SaaS, no API keys, no cloud. Just a single binary.

What's new in v0.1.5:

✅ Live threat feeds from 6 sources — Socket.dev, OSV.dev, GitHub Advisory DB, Cisco Talos, Unit 42, BleepingComputer
✅ uv support — detects Python packages installed via uv pip and uv tool
✅ Venv scanning — walks your project directories for virtual environments
✅ Windows Scripts/ path support
✅ 165 new malicious packages added — TrapDoor, Axios/Lazarus, CanisterSprawl, Contagious Interview, Solana typosquats
✅ 19 malware families tracked — PamDOORa, Quasar Linux RAT, CloudZ RAT, Nitrogen, and more
✅ GitHub token integration for live GHSA updates (optional, works without it)
One command to install:

`bash`

curl -fsSL https://lnkd.in/dTv3ukhe | bash

Open source. MIT license. Cross-platform.

https://github.com/firfircelik/libkill

The Comforting Lie Of SHA Pinning

Wed, 13 May 2026 09:19:41 +0000

Originally published at https://www.vaines.org/posts/2026-03-24-the-comforting-lie-of-sha-pinning/

In March 2026, Trivy became the latest reminder that software supply chains are, at best, loosely held together with convention and trust.

A typosquatting attack slipped malicious code into what looked like a legitimate dependency path. The post-mortems are worth reading, and they all converge on a single recommendation: pin your dependencies. In the GitHub Actions world, that usually translates to use commit SHAs, not tags.

There’s a widely held belief that pinning a GitHub Action to a commit SHA gives you immutability, its what Microsoft/GitHub are recommending, and its what Aqua are recommending. After all, a SHA is content-addressed. It cannot be moved. It cannot be re-tagged. It is, in theory, the most stable reference you can use. The problem with that line of thinking is that the resolution of that SHA is not scoped the way most people assume. Specifically, GitHub Actions does not meaningfully validate that the commit SHA you reference belongs to the repository you think it does.

Wait, what? No, thats not right...

I set up a deliberately small example to test this behaviour.

A “legitimate” action: avaines/blog_gh_sha_pinning_action
A consuming application: avaines/blog_gh_sha_pinning_app

The application references the action in the usual way:

uses: avaines/blog_gh_sha_pinning_action@<some-sha>

So far, so normal.

Now introduce an attacker:

Fork the action repository to aidenvaines-cgi/blog_gh_sha_pinning_action
Add a malicious step (in my case, just printing output, but in reality this is where you exfiltrate all the fun stuff like secrets and personal data)

Next, create a pull request to the consuming application that appears to simply bump the pinned SHA:

The SHA used in the PR comes from the attacker-controlled fork of the action, despite it still being referenced as avaines/blog_gh_sha_pinning_action

You might reasonably assume one of the following safeguards exists:

GitHub validates that the SHA belongs to avaines/blog_gh_sha_pinning_action
Or the workflow fails because the commit cannot be found in the specified repository

Neither is true, and that is madness

The workflow executes successfully!!!!!!!

GitHub resolves the commit SHA, finds a matching object, and executes it, regardless of which fork it originated from.

From the platform’s perspective, a fork is a separate repository with a shared object graph/history. When the runner resolves the reference, it ultimately looks up the commit in the Git object database; if that object exists and is reachable, it can be used regardless of which fork introduced it. A commit object is globally identifiable. If the SHA exists anywhere reachable, that is apparently sufficient.

The result is that a pull request can replace a pinned, trusted action with attacker-controlled code without changing the apparent repository reference.

If the reviewer is scanning for obvious changes like owner, repo name, or tag they will see none.

Only the SHA changes and with that comes a huge amount of assumed trust. I know that owner, and I know that repository, its just a version bump, and a minor one at that, with that comment next to the tag doing a lot of heavy lifting. We’ve just spent the last few years training people to treat that as best practice.

A lot of the current guidance focuses on avoiding tags because they are mutable, which is true: tags can be moved, and relying on them introduces an entirely different risk. Github already has a 'Make tags immutable' feature, but it's optional, therefore, neither used nor can it be trusted as the owner (or attacker) could just disable it.

Simply switching to SHA pinning does not eliminate the problem, in some respects it makes it worse. Tags are scoped to owner/repository because thats how they work. You could argue its harder to compromise that repository rather than hijack it through a forked repository and then writing actual changes to the repository. Whereas a commit object is content-addressed and can be reachable from multiple repositories that share history (e.g. forks)

I believe the industry advice is a bit of an overcorrection, and we’ve replaced one weak guarantee (mutable tags but scoped to repo) with another vastly worse idea in unscoped SHAs. Yes you should check, yes you should validate it, but tags are human readable, SHAs are not and if you ask yourself "Do I always properly check?" do you? because I can't say I do enough validation 100% of the time.

Supply Chain Woes

The Trivy incident is not interesting because of the tool. Though it is the thing that's caused me a lot of bother over the last month, and its symptomatic of the constant supply chain threats we're seeing everywhere. Late last year NPM was basically a skip fire (https://www.wiz.io/blog/widespread-npm-supply-chain-attack-breaking-down-impact-scope-across-debug-chalk, https://www.wiz.io/blog/shai-hulud-npm-supply-chain-attack, etc). We've delegated so much behaviour to 3rd parties we can't, and shouldn't implicitly trust. The https://www.npmjs.com/package/is-odd package became a bit of a meme for this exact problem, where tool chains like NPM and GitHub Actions place re-usable custom modules/actions/libraries as an attractive off the shelf solution to solve common problems so you don't have to.

Ironically with the rise of AI, it's now easier to just vibe code the same functionality yourself that use one of these off the shelf resources, and you can still know exactly as much about how security, your data, and to some extent the functionality works with strangely more ownership and a smaller attack service.

GitHub Actions, in particular exacerbates this somewhat as workflows routinely execute third-party code, the secrets are implicitly available to those workflows and there are multiple ways to extract those at runtime with little audit or oversight. Then to top it all off SHAs are not human friendly and tags are not immutable so review processes tend to focus on what changed, not *where it came from. Which is all a fragile house of cards, sometimes I miss Jenkins.

If “use SHAs” is not sufficient, what is?

At a minimum, we need to introduce provenance checks. I've said above that SHA's are not human friendly like tags so theres a couple of things we can, and probably should be doing to validate. Obviously that the SHA or tag exists in the right repository and GitHub should enforce tag mutability in my opinion:

We tend to describe these incidents as “supply chain attacks”, which is accurate but slightly misleading. It implies a complex and sophisticated multi-stage compromise by 1337 h4x0rz. In reality, the weakest link is often much simpler because humans are a bit shit sometimes. SHA pinning being touted as the solution is just security-theater rather than due diligence in an ecosystem that is not helping either.

S&OP Engineering IV: Scaling to Enterprise (Multi-SKU & Bottlenecks)

Mon, 06 Apr 2026 05:55:15 +0000

Your MVP works. One product, one model, one perfect plan. Congratulations: you just solved the easiest problem in Supply Chain.

Now add 3 products sharing the same factory. Product A needs 14,000 units in July. Product C needs 13,000 that same month. Your factory produces 15,000. Who gets shorted?

If your answer is "we'll figure it out in Thursday's meeting," your company has an engineering problem, not a management one.

Executive Summary: In chapters 1, 2 and 3 we built a working MVP for a single product. In this Chapter 4, we break it. We inject 3 years of history with 3 SKUs of radically different demand profiles (Core, Intermittent, and Seasonal), parallelize Prophet model training with MLOps, and build a unified Linear Programming model where products compete mathematically for limited factory capacity. Welcome to Theory of Constraints executed in code.

The Fatal Error: Optimizing in Silos

The biggest sin in Supply Chain Planning isn't using dirty data (we fixed that in Chapter 1). It's optimizing each product as if the factory were infinite.

Imagine three product managers, each with their optimized Excel:

SKU-001 Manager (Core): "I need to produce 6,000/month. Already calculated."
SKU-002 Manager (Spare Part): "I only need 15/month. No big deal."
SKU-003 Manager (Seasonal): "In July I need 14,000. Non-negotiable."

Sum: 6,000 + 15 + 14,000 = 20,015 units. Your factory produces 15,000. Each manager is right individually. Collectively, it's a collapse.

This is what Eli Goldratt described in The Goal as Theory of Constraints: the system is not optimized by summing local optima. It's optimized by identifying the bottleneck and letting mathematics allocate the resources.

Stress-Test: The 3 Profiles That Break Your MVP

To validate the Enterprise architecture, we generated a 3-year dataset (2023-2025) with three SKUs designed to break any naïve model:

SKU	Profile	Average Demand	Trap
SKU-001	Core Product	~200/day	High variance + 3x Black Friday
SKU-002	Intermittent Spare	~0.6/day	70% zero-demand days
SKU-003	Seasonal Summer	~250/day	500+ peaks in July, zero in winter

We injected real ERP noise: outliers (x50), corrupted dates, nulls, negatives. This isn't a toy tutorial. It's what comes out of a production SAP on any given Tuesday.

MLOps: Parallelizing the Forecasting

With a single product, training Prophet takes 2 seconds. With 50 SKUs in a for loop, you wait 100 seconds. With 500, you go home.

The solution is the same one production pipelines use: parallelization. Each SKU is statistically independent, so each model can train on its own thread:

from concurrent.futures import ThreadPoolExecutor

def process_sku(sku, df_sku, months, country_code):
    """Worker: trains Prophet for one SKU."""
    predictor = ProphetPredictor(df_sku, sku_name=sku)
    predictor.preprocess_daily_aggregation()
    predictor.train_model(country_code=country_code)
    return predictor.generate_forecast(months=months)

with ThreadPoolExecutor(max_workers=3) as executor:
    futures = {
        executor.submit(process_sku, sku, df, 12, "ES"): sku
        for sku, df in sku_dataframes.items()
    }

3 Prophet models, 3 seconds. Not 6. Three. If you add 50 SKUs like any mid-sized company has, the difference between sequential and parallel is the difference between an operational pipeline and a script nobody wants to run.

Negative Clipping: The Business Rule Prophet Ignores

Prophet can generate negative predictions. Mathematically it makes sense (the regression doesn't know demand can't be -12 units). Operationally it's a disaster.

Our forecasting_engine_v2.py applies a Negative Clipping post-prediction:

# Business Rule: Demand cannot be negative
for col in ["yhat", "yhat_lower", "yhat_upper"]:
    self.forecast[col] = self.forecast[col].clip(lower=0)

One line. One fewer production bug. This is what separates MLOps from "Machine Learning in a Jupyter Notebook."

Fault Tolerance: One SKU Doesn't Kill the Pipeline

What happens if SKU-002 has only 10 records and Prophet fails? In an amateur script, the entire pipeline dies. In an Enterprise system:

sku_name, forecast_df, error = future.result()
if error:
    print(f"[!!] {sku_name}: FAILED - {error}")
    result["skus_failed"] += 1
else:
    forecasts.append(forecast_df)
    result["skus_success"] += 1

The 2 healthy SKUs finish their work. The failed one gets logged. This is the difference between a script and a system.

The Mathematics of Bottlenecks: Unified PuLP Model

Here's the intellectual core of the entire chapter. In Chapter 3 we optimized one product. Now we create a single LP model where all SKUs coexist:

# ── MULTI-DIMENSIONAL decision variables ──
production[sku][t]  # How much to produce of SKU s in period t
inventory[sku][t]   # Inventory of SKU s at end of period t

# ── Objective Function: TOTAL system cost ──
problem += lpSum(
    prod_cost[sku] * production[sku][t]
    + hold_cost[sku] * inventory[sku][t]
    for sku in skus for t in range(T)
), "Total_System_Cost"

# ── THE KEY CONSTRAINT: Shared Capacity ──
for t in range(T):
    problem += (
        lpSum(production[sku][t] for sku in skus) <= SHARED_MAX_CAPACITY,
        f"SharedCapacity_t{t}"
    )

Read that last constraint. It's a single line of code, but it contains Goldratt's entire Theory of Constraints encoded:

lpSum(production[sku][t] for sku in skus) <= 15,000

You're telling the machine: "The factory produces at most 15,000 units per month. I don't care if it's 15,000 of SKU-001 or 7,500 of each. You decide the allocation that minimizes total system cost."

And the solver decides. No meetings. No politics. No "we always prioritize the big client." Mathematics.

The Result: Intelligent Capacity Allocation

Our solver with real Supabase data:

  SKU-001: demand=70,879 | prod=70,579 | avg_inv=5,754 | cost=855,394 EUR
  SKU-002: demand=143   | prod=128   | avg_inv=6     | cost=6,775 EUR
  SKU-003: demand=84,298 | prod=84,098 | avg_inv=115   | cost=1,265,970 EUR

  Total production cost:       1,973,660 EUR
  Total holding cost:            154,479 EUR
  ** TOTAL SYSTEM COST:        2,128,139 EUR **

Observe the decisions the algorithm made:

SKU-001 (prod_cost=€10, hold_cost=€2): Cheap to store. The solver produces ahead during cheap months and stockpiles inventory (avg 5,754 units). Intelligent pre-build.
SKU-002 (prod_cost=€50, hold_cost=€5): Expensive part. Strict just-in-time production (avg_inv=6 units). Doesn't stockpile a single extra piece.
SKU-003 (seasonal): Minimum inventory at safety stock. Produces exactly what it needs each month, following the seasonal wave.

No human with Excel can calculate this with 3 products and 13 months. And they definitely can't recalculate it every week when the forecast changes.

The Ah-Ha Moment: The Bottleneck Visualized

Look at the summer months. Combined demand from the 3 SKUs exceeds factory capacity (red line). What does the algorithm do? Instead of breaking stock, it decides to advance production of the cheapest-to-store SKU (SKU-001) to spring, freeing factory space for the critical seasonal product (SKU-003) in summer. This is Theory of Constraints executed by a machine.

If you look at the chart, it seems like SKU-002 (spare parts) doesn't exist. But it's there. It represents 0.1% of the factory's volume, but in manual management, it usually consumes 20% of the planner's mental time due to its high volatility. By delegating this to a Linear Programming model, the system manages large volumes and the long tail simultaneously without stress.

Open Kitchen: Break the System

I distrust theories that can't be put into practice. I've prepared a new Enterprise Google Colab where you can run the most revealing experiment of the entire series:

Lower the SHARED_MAX_CAPACITY variable to 12,000. Watch the solver start juggling: it sacrifices SKU-001 inventory to prioritize SKU-003 in July. Lower it to 10,000 and you'll see the model declare INFEASIBLE — the factory literally cannot meet demand even with the best possible planning. That's your inflection point for investing in capacity expansion.

Open the Multi-SKU Enterprise Google Colab

Change the maximum factory capacity, modify holding costs, add a fourth SKU. Do engineering, not faith.

The Full Chain: From MVP to Enterprise

With this fourth chapter, we've scaled a single-product prototype to a Multi-SKU Enterprise architecture:

Next Step: The Autonomous Brain

Our Supabase database now has the perfect master plan. Three products, thirteen months, every unit assigned to the optimal month considering costs, seasonality, and physical capacity.

But databases don't send emails to suppliers. They don't negotiate with plant directors. They don't generate purchase orders at 6am on Monday.

In Chapter 5 (Grand Finale), we'll connect this plan to AI Agents (CrewAI) to execute operations autonomously. The algorithm decides how much to buy. The agent executes the purchase. The human... supervises.

The difference between a company that plans and one that optimizes is a mathematical model between its data and its decisions. And between its decisions and its actions, an autonomous agent.

Russian hackers crippled Toyota by attacking a cup holder suppliers threatening U.S. defense.

Fri, 08 Aug 2025 23:03:16 +0000

From Cup Holders to Aircraft Carriers: How Nation-State Attackers Exploit the Defense Supply Chain's Weakest Links

Horizon3.ai's CEO reveals why compromising a small Tokyo parts supplier can shut down Toyota—and what this means for U.S. national security

When Russian hackers wanted to retaliate against Japanese support for Ukraine, they didn't target Toyota directly. Instead, they ransomwared a small company in Tokyo that made cup holders. Due to lean manufacturing and just-in-time logistics, Toyota was forced to shut down 28 production lines, suffering nearly $400 million in economic damage, all over cup holders.

This real-world example, shared by Snehal Antani, CEO and co-founder of Horizon3.ai, during our interview at Black Hat 2025, perfectly illustrates a critical vulnerability in modern supply chains: attackers don't need to go after the big targets when they can achieve maximum impact by hitting the smallest suppliers.

"The flex by the Russians was knowing where to apply the least amount of effort to cause the maximum amount of pain," Antani explained. "They don't have to attack Toyota directly. They can go after the long tail of suppliers."

The 77-Second Reality Check

This principle has profound implications for U.S. national security, as Antani and his team at Horizon3.ai have discovered through their work with the NSA's Defense Industrial Base (DIB). Having completed over 150,000 penetration tests, including direct collaboration with the NSA Cybersecurity Collaboration Center, Horizon3.ai has uncovered some alarming realities about our defense supply chain's security posture.

The most shocking revelation? Antani's team once hacked a defense contractor in just 77 seconds, and in less than five minutes, they compromised a ship welding company and gained access to 3D CAD drawings for Nimitz-class aircraft carriers and nuclear submarines.

"If we hack you in 77 seconds, you have 76 seconds to stop us," Antani noted. "Could your team stop it? Could you detect it? Did you actually get approval to do some sort of defensive or cycling action? The answer is probably not."

Beyond Compliance: The False Security of Checkboxes

What makes these rapid compromises particularly concerning is that every single defense industrial base company Horizon3.ai compromised was compliant with some security framework—SOC 2, NIST, or others. They had all conducted annual penetration tests and tabletop exercises.

"Just because you're compliant doesn't mean you're secure," Antani emphasized. "Those one-and-done acts of assessing your security posture are not going to cut it in the current era."

The fundamental problem isn't sophisticated zero-day exploits or advanced persistent threats. Instead, attackers are succeeding through surprisingly mundane methods: compromised credentials and misconfigurations in software and security tools.

"Attackers don't hack in. They log in," Antani explained. "Credentials are the everyday zero-day. Your credential attack surface is the most susceptible."

The Speed of Modern Warfare

The velocity of these attacks reflects a broader shift in cybersecurity. Antani predicts that "the future of cyber warfare is algorithms fighting algorithms, with humans by exception." Traditional security models built around human response times simply cannot keep pace with automated attack tools.

To address this reality, Horizon3.ai has moved customers from conducting one or two penetration tests per year to 40-50 tests per month through their Continuous Autonomous Penetration Testing (CAPT) service.

"Think of it as: for every Patch Tuesday, you have a penetration test," Antani said. "The more you test, the higher your resolution of your security. Think of it as a radar sweep, you have a really slow radar sweep, you're going to miss a lot of threats."

Supply Chain Warfare: A National Security Imperative

For defense contractors, supply chain attacks represent a unique threat vector with three primary objectives: stealing intellectual property, using suppliers as launch pads to swim upstream to larger targets, and causing production delays that can set critical weapons programs back years.

"If I can cause delays in these critical suppliers, then as you add those delays up, the aircraft carrier is 10 years behind," Antani explained. "We expect to see persistent cyber engagement against the long tail of suppliers that provide support for specific weapons platforms."

This strategy is already being observed in the wild. Nation-state actors are identifying suppliers for platforms like the F-22 fighter jet and conducting persistent cyber operations specifically designed to delay production timelines.

AI: The Double-Edged Sword

As cybersecurity professionals begin leveraging AI for defense, Antani acknowledges that adversaries will adopt the same technologies. However, he sees promise in structured approaches to AI implementation, particularly through Model Control Protocol (MCP) servers.

Horizon3.ai recently announced its MCP server, which allows security teams to use natural language interfaces with tools like Claude to run penetration tests, understand exploitation methods, and generate fixes.

"I think MCP servers are going to be the most impactful thing in the near term," Antani said. "The concept of a natural language, headless interface to your tools, dramatically simplifies the effort to integrate."

Moving from Reactive to Proactive

For security leaders, Antani advocates a fundamental mindset shift from reactive compliance to proactive verification. Drawing from his special operations background, he quotes a former commander: "Don't tell me I'm secure. Show me, and then show me again tomorrow, and then show me again next week."

This philosophy distinguishes between being "secure," a point-in-time state, and being "defensible," which requires continuously adapting to attackers and preventing them from achieving their objectives.

For developers and engineers on the front lines, Antani offers practical advice: "Being vulnerable to an issue doesn't mean you're actually exploitable. The only perspective that matters in cybersecurity is the attacker's perspective, looking at your environment through the eyes of the attacker."

The Road Ahead

As the cybersecurity industry grapples with tool sprawl and vendor hype, Antani advocates for a back-to-basics approach focused on proving rather than promising security. His company's partnership with the NSA represents a model for how government and private sector collaboration can address the most critical vulnerabilities in our national infrastructure.

The lesson from the Toyota cup holders extends far beyond automotive manufacturing. In an interconnected world where small suppliers can bring down giants, security is only as strong as the weakest link in the chain. For the Defense Industrial Base, that means recognizing that national security depends not just on protecting prime contractors, but on securing every machine shop, CNC factory, and ship welder in the supply chain.

The question isn't whether nation-state actors will continue targeting these vulnerable suppliers—it's whether we'll act fast enough to defend them.

A Deep Dive into Decentralized Provenance Tracking and Smart Contracts

Fri, 28 Mar 2025 22:39:54 +0000

The global supply chain is a complex web of interconnected processes, often plagued by inefficiencies, lack of transparency, and susceptibility to fraud. While blockchain technology has been touted as a solution, most discussions focus on its application in finance or NFTs. However, Web3 offers a suite of lesser-known services that can revolutionize supply chain management. By combining decentralized provenance tracking, tokenized asset representation, and smart contract automation, businesses can achieve unprecedented levels of transparency, efficiency, and trust.

The Problem: Opaque Supply Chains and Counterfeit Goods

Consider a luxury fashion brand, Elegance Couture, that sources materials from multiple countries, manufactures products in different regions, and distributes them globally. The brand faces two major challenges:

Lack of Transparency: Customers and stakeholders cannot verify the authenticity or ethical sourcing of materials.

Inefficient Processes: Manual tracking and reconciliation of supply chain data lead to delays and errors.

Elegance Couture needs a solution that ensures end-to-end transparency, automates supply chain processes, and builds trust with its customers.

The Web3 Solution: A Triad of Decentralized Services

To address these challenges, Elegance Couture can leverage three advanced Web3 services:

Decentralized Provenance Tracking
Platforms like OriginTrail or Provenance use blockchain to create immutable records of a product’s journey from raw materials to the end consumer. Each step in the supply chain is logged on a decentralized ledger, ensuring transparency and traceability.

Tokenized Asset Representation
By tokenizing physical assets (e.g., raw materials, finished products) on platforms like Polymath or Harbor, Elegance Couture can create digital twins of its products. These tokens represent ownership, authenticity, and other metadata, enabling seamless tracking and verification.

Smart Contract Automation
Smart contracts on networks like Ethereum or Polkadot can automate supply chain processes, such as payments, quality checks, and compliance reporting. These self-executing contracts reduce manual intervention and ensure accuracy.

The Process: How It All Comes Together

Step 1: Provenance Tracking
Elegance Couture integrates decentralized provenance tracking into its supply chain. Each material supplier logs the origin, quality, and ethical certifications of their products on the blockchain. As the materials move through the supply chain, every transaction and transformation is recorded.

Step 2: Tokenization of Assets
Once the materials are transformed into finished products, Elegance Couture creates tokenized representations of each item. These tokens include details such as the product’s origin, manufacturing process, and authenticity. Customers can scan a QR code to access this information.

Step 3: Smart Contract Automation
Smart contracts are deployed to automate key processes. For example, when a shipment reaches a distributor, a smart contract triggers an automatic payment to the manufacturer. Similarly, quality checks and compliance reports are automatically logged and verified.

The Utility and Benefits

Enhanced Transparency: Customers can verify the authenticity and ethical sourcing of products, building trust and loyalty.

Fraud Prevention: Immutable records on the blockchain make it nearly impossible to introduce counterfeit goods into the supply chain.

Operational Efficiency: Automation reduces manual errors, speeds up processes, and lowers costs.

Sustainability: Ethical sourcing and transparent practices align with global sustainability goals, enhancing the brand’s reputation.

Why Choose Web3Dev for Your Supply Chain Transformation?

Implementing a Web3-powered supply chain solution requires expertise in blockchain integration, smart contract development, and system interoperability. This is where Web3Dev excels. As a leading Web3 development agency, Web3Dev specializes in creating tailored solutions that leverage decentralized technologies to solve real-world problems. Our team can design and deploy a comprehensive system for provenance tracking, asset tokenization, and process automation, ensuring a seamless and secure experience for businesses like Elegance Couture.

By partnering with Web3Dev, you’re not just adopting cutting-edge technology, you’re setting a new standard for transparency and efficiency in your industry.

In conclusion, the combination of decentralized provenance tracking, tokenized asset representation, and smart contract automation represents a game-changing approach to supply chain management. These Web3 services, though less known, hold immense potential to transform industries and build trust in global markets. For businesses ready to embrace this future, Web3Dev is the ideal partner to guide you through the complexities and unlock the full power of Web3.