6 posts tagged with "Compliance"

Ask a team which AI their product uses and you will usually get one answer: the provider on the invoice. Then look at the code. There is the SDK everyone knows about, a second provider someone added for embeddings, a model name hardcoded in a background job, a LangChain agent in an internal tool, a .pt file checked into a test folder, and an MCP server declared in a config file that nobody remembers adding.

None of that is unusual. AI components arrive the way dependencies always have: one import at a time, by whoever needed them that week. The difference is that more people now want a list. Regulators, customers' security reviews and your own incident response all start with the same question, and "we use one provider" is rarely the full answer.

Ask a supplier for an SBOM and VEX and you get two files that answer two different questions. The SBOM (software bill of materials) answers "what is in this product?". The VEX (Vulnerability Exploitability eXchange) answers "of the advisories that match those components, which ones actually affect this product?". The first is an inventory. The second is a verdict, and a verdict is only as good as the evidence behind it.

This post covers what each document records, what the VEX statuses and not_affected justifications mean in the CISA and OpenVEX vocabulary, and why a not_affected claim needs reachability evidence before anyone should trust it. It ends with the commands Vulkro Core uses to produce both on your own machine.

If you sell software to an Indian bank, a government department or an essential services operator, sooner or later a questionnaire will ask whether your SBOM follows the CERT-In SBOM guidelines. The document it means is CERT-In's Technical Guidelines on SBOM, QBOM & CBOM, AIBOM and HBOM, version 2.0, dated 9 July 2025. It is longer and more demanding than the US baselines most SBOM tools were built for.

This post covers who the guidelines are aimed at, the 21 data fields they list as minimum elements, what they say about vulnerability status, and how to generate an SBOM and check it against those fields before a customer does.

Every SOC 2 audit gets to the same question about engineering: show me that changes to the software were reviewed before they reached production. ISO 27001 asks a close cousin: show me that you develop securely and test what you build. Teams usually answer with screenshots of a pull request, a scanner dashboard and a spreadsheet stitched together the week before fieldwork. SOC 2 code scanning evidence is better when it comes from the scan itself, already mapped to the controls.

This post covers what the two frameworks actually ask for, which parts of that a code scanner can honestly support, and which parts it cannot. Then it shows the evidence Vulkro Core produces. One point up front: a scanner does not make anyone compliant, and neither SOC 2 nor ISO 27001 is something a tool can grant.

Air-gapped SAST sounds simple: run the static analysis on a machine with no network. In practice, many tools that run locally still expect the internet somewhere. A licence check calls home, a dependency lookup goes to a public API, an explanation is fetched from a hosted model. On a classified or regulated network, any of those calls stops the tool from being approved.

The code that most needs review often sits on exactly those networks: defence programmes, government systems, payment and core banking platforms. This post sets out what offline scanning actually requires, how to keep vulnerability data current across the gap, and how Vulkro's command-line tools handle each part.

PCI DSS 4.0 requirement 6 is the part of the card industry standard written for the people who build software. If your application stores, processes or transmits cardholder data, or can affect the security of the systems that do, your assessor will ask how its code is reviewed, how it is protected against common attacks and what third-party components it contains. They will want evidence for each answer, not a policy that says it happens.

This post walks through the parts of requirement 6 that land on engineering teams (6.2.3 code review, 6.2.4 attack prevention and 6.3.2 the software inventory), what automated code scanning can contribute to each, and where it stops. It ends with the evidence Vulkro Core produces against the PCI DSS 4.0 requirements it maps.