India software supply chain and AI security rules: a 90-day plan

If you build, buy or run software in India, four sets of rules decide most of what your security programme must prove: the CERT-In Directions of 28 April 2022 (six-hour incident reporting and 180 days of logs kept in India), sector rules from SEBI and RBI that now ask for SBOMs, vendor assurances and timed vulnerability fixes, and the Digital Personal Data Protection Act 2023 with its Rules notified on 13 November 2025, whose main duties start on 13 May 2027. AI is governed for now by principles and existing law rather than a dedicated statute. This guide lays out each rule from its primary text, the evidence a supervisor or auditor will ask for, and a 30/60/90-day plan that works with whatever tools you already have.

This is a practical reading of public documents, not legal advice. Where a rule needs interpretation for your entity, take it to counsel or your regulator.

Key takeaways

• CERT-In Directions (in force since late June 2022) apply to service providers, intermediaries, data centres, body corporates and government organisations. Report listed incident types within 6 hours, keep ICT logs for a rolling 180 days (the Direction says within Indian jurisdiction; CERT-In's FAQ adds nuance), sync clocks to NIC or NPL time, and name a point of contact.
• CERT-In's SBOM guidelines are now Version 2.0 (dated 9 July 2025) and cover SBOM, QBOM and CBOM, AIBOM and HBOM. They are technical guidance, and they encourage departments to make SBOMs a mandatory part of procurement.
• SEBI's CSCRF (circular of 20 August 2024) makes SBOMs mandatory for critical systems under standard GV.SC.S5 and requires 6-hour incident reporting to SEBI and CERT-In. The last general extension ran to 31 August 2025 for most regulated entities.
• RBI's Master Direction on IT governance (7 November 2023, in effect from 1 April 2024) asks banks and covered NBFCs for vendor confirmation that applications are free of known vulnerabilities, six-monthly VA, annual PT for critical systems, and time-bound fixing.
• DPDP Rules 2025 phase in: Board provisions on 13 November 2025, consent manager registration on 13 November 2026, and security safeguards (Rule 6), breach intimation with a 72-hour detailed report (Rule 7) and most other duties on 13 May 2027.
• India AI Governance Guidelines set out seven sutras and recommend new institutions and a national AI incident database. They lean on existing law and voluntary measures, not a new AI act.
• Safeguard capabilities covered here, all GA: SBOM generation and analysis, SCA and vulnerability management with EPSS and KEV, reachability analysis, policies and gates, autonomous remediation (ships switched off), license compliance, CSAF and VEX upload, the Compliance and GRC suite with India CERT-In and India DPDP framework pages, TPRM SBOM requests, Trust Center, AI-BOM discovery, AI-SPM, AI Gateway, MCP Guardrail, agent identity, Package Firewall, the CLI and local runner, Zero AI mode, bring your own model, private VPC, on-prem and air-gapped deployment.

Who this applies to in India

India has no single horizontal software security law. Obligations stack by who supervises you, and most organisations sit under at least two layers.

Software vendors to Indian banks and market intermediaries are not regulated entities, but RBI and SEBI push obligations onto them through contracts: SBOMs, vulnerability assurances and source code escrow. Foreign SaaS companies with Indian customers should read CERT-In's FAQ, which says the Directions apply to any entity in the matter of cyber incidents, and the DPDP Act, which applies if they process personal data of people in India in connection with offering goods or services to them.

For insurers we could not retrieve IRDAI's primary guideline text today, so this guide does not describe its clauses. Read IRDAI's own circulars before you plan against them.

The rules, regulator by regulator

CERT-In Directions of 28 April 2022

The Directions (No. 20(3)/2022-CERT-In) were issued under section 70B(6) of the Information Technology Act, 2000 and took effect 60 days after issue. They apply to "service providers, intermediaries, data centres, body corporate and Government organisations". The clauses that matter for software teams:

• Direction (i), time sync. Connect ICT systems to the NTP servers of the National Informatics Centre (NIC) or National Physical Laboratory (NPL), or to sources traceable to them. Multi-region estates may use another accurate source as long as it does not deviate from NPL and NIC.
• Direction (ii), 6-hour reporting. Report the incident types in Annexure I "within 6 hours of noticing such incidents or being brought to notice about such incidents". Annexure I includes targeted scanning of critical systems, compromise of critical systems or information, unauthorised access to IT systems or data, website defacement and intrusion, and more.
• Direction (iii), point of contact. Designate a point of contact for CERT-In and act on CERT-In orders within the timeframe they specify, including near real-time information where asked.
• Direction (iv), logs. Enable logs of all ICT systems and keep them securely for a rolling 180 days "within the Indian jurisdiction", and provide them with any incident report or on CERT-In's order. CERT-In's May 2022 FAQ softens the location point: its answer to question 35 says logs "may be stored outside India" as long as they can be produced to CERT-In in reasonable time, while its answer to question 36 says any service provider offering services to users in India must maintain logs and financial transaction records in Indian jurisdiction.
• Directions (v) and (vi) add five-year subscriber and KYC records for hosting, VPN and virtual asset providers.

Failure to comply may invite action under section 70B(7) of the IT Act. On scope, the FAQ's answer to question 26 says the Directions "are applicable to any entity whatsoever" in the matter of cyber incidents, pointing to sections 1 and 75 of the IT Act. Our related posts on the Directions in plain language cover it.

CERT-In SBOM technical guidelines, Version 2.0

CERT-In's "Technical Guidelines on SBOM, QBOM and CBOM, AIBOM and HBOM", Version 2.0, is dated 9 July 2025 and is the version listed on CERT-In's site today. It is guidance, not a direction under section 70B(6). It is addressed to "entities, particularly those in the public sector, government, essential services, organizations involved in software export and software services industry", and says departments and organisations are encouraged to make SBOMs "a mandatory standard practice" in procurement and development.

Version 2.0 widens the scope with chapters on a Quantum BOM and Cryptographic BOM (chapter 8), an AI Bill of Materials (chapter 9) and a Hardware BOM (chapter 10). The SBOM core is unchanged in spirit:

• Minimum elements (Table 5). Data fields for each component: name, version, description, supplier, license, origin, dependencies, vulnerabilities, patch status, release date, end-of-life date, criticality, usage restrictions, checksums or hashes, comments, SBOM author, timestamp, executable, archive and structured properties, and a unique identifier.
• Automation support. Machine-readable SPDX or CycloneDX.
• Practices and processes. Frequency, depth, known unknowns, distribution and delivery, access control, and accommodation of mistakes.
• Levels. Top-level, n-level, delivery, transitive and complete SBOMs. The guideline recommends a customised SBOM for consumers and an internal SBOM at the complete level, with vulnerability updates shared with the consumer periodically.

The AIBOM minimum elements in Table 10 are model name, version, type and developer, licensing, software dependencies, ML models and algorithms, performance metrics, data source, data sets, hardware, security requirements, input, output and intended usage. For a deeper field-by-field walk, see CERT-In SBOM guidelines Version 2 explained.

CERT-In's guidelines page also now lists a document titled "Blueprint for Reducing Exposure and Defending against AI-Assisted Vulnerabilities Exploitation in Digital Infrastructure". We confirmed only that the title appears there; read it on CERT-In's site before relying on any of its contents.

SEBI Cybersecurity and Cyber Resilience Framework (CSCRF)

SEBI issued the CSCRF by circular SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2024/113 on 20 August 2024. It applies to a long list of regulated entities (REs), from stock exchanges and depositories to brokers, mutual funds, portfolio managers and investment advisers, with graded obligations by RE category. Standards are labelled by function, in a structure that follows Govern, Identify, Protect, Detect, Respond and Recover.

The software supply chain clauses:

• GV.SC.S5, SBOM. REs "shall obtain SBOM for existing their critical systems within 6 months" of the framework's issue, and shall obtain SBOMs for any new critical systems software products or SaaS applications at procurement. Market infrastructure institutions shall include SBOM in their empanelment criteria for application software vendors. The SBOM shall include, at least, license information, supplier name, all primary components with their transitive dependencies and relationships, encryption used, cryptographic hashes, frequency of updates, known unknowns, access control, and methods for accommodating occasional errors.
• Supply chain risk (GV.SC). Third-party providers are identified and assessed, legacy systems without an SBOM need approval with a documented rationale, and GV.SC.S7 asks REs to identify providers that create concentration risk.
• Incident reporting (RS.CO.S3). Incidents covered by the CERT-In Directions are reported to SEBI and CERT-In within 6 hours of noticing or detecting them.

Dates. The original circular set 1 January 2025 for six RE categories that already had cyber circulars and 1 April 2025 for the rest. SEBI then extended. Its circular SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2025/96 of 30 June 2025 moved compliance to 31 August 2025 for all REs except market infrastructure institutions, KYC registration agencies and qualified RTAs. That date has passed. If you are a SEBI RE, the framework is live for you now, and an auditor will test it. Our SEBI CSCRF SBOM requirements post goes deeper on the SBOM clause alone.

RBI Master Direction on IT Governance, Risk, Controls and Assurance Practices

RBI issued this Master Direction (RBI/2023-24/107, DoS.CO.CSITEG/SEC.7/31.01.015/2023-24) on 7 November 2023, and it came into effect on 1 April 2024. It applies to commercial banks (excluding regional rural banks), NBFCs in the top, upper and middle layers, credit information companies and the all India financial institutions. Foreign bank branches follow a "comply or explain" approach. Local area banks and NBFC core investment companies are excluded.

The clauses that land on software:

• Paragraph 12(f). Obtain source code for all critical applications from vendors, or put a source code escrow arrangement in place that includes all product updates and fixes.
• Paragraph 12(g). Obtain "a certificate or a written confirmation from the application developer or vendor stating that the application is free of known vulnerabilities, malware, and any covert channels in the code", again whenever material code changes, including upgrades, occur.
• Paragraph 26, VA and PT. For critical systems and those in the DMZ with customer interfaces, vulnerability assessment at least once every six months and penetration testing at least once every 12 months, plus testing across the lifecycle. Testers must be trained and independent. Fix identified vulnerabilities "in a time-bound manner" and stop known CVEs from recurring. Document the approach, including the scoring mechanism such as CVSS.
• Paragraph 27(d), incidents. Notify CERT-In and RBI proactively as per regulatory requirements.

RBI periodically consolidates and reissues directions, so confirm the version that applies to your entity type on RBI's Master Directions page before you map controls. For a clause-by-clause checklist, see the RBI evidence checklist.

Digital Personal Data Protection Act 2023 and DPDP Rules 2025

The DPDP Act (Act No. 22 of 2023) was published on 11 August 2023. The Rules were notified in the Gazette of India on 13 November 2025 (G.S.R. 846(E)). Rule 1 sets the phasing:

The software-relevant duties:

• Section 8(5) and Rule 6, reasonable security safeguards. At a minimum: encryption, obfuscation, masking or tokenisation; access control on computer resources; visibility through logs, monitoring and review; continued processing through measures such as backups; retention of those logs and personal data for one year unless another law says otherwise; contract clauses that bind data processors to safeguards; and appropriate technical and organisational measures.
• Section 8(6) and Rule 7, breach intimation. Tell each affected data principal without delay. Tell the Board without delay, then within 72 hours of becoming aware provide detail: facts, circumstances, reasons, mitigation, findings about who caused it, remedial measures and the notices sent.
• Rule 13, significant data fiduciaries. An annual DPIA and audit with a report to the Board, due diligence that "algorithmic software" used to process personal data is not likely to pose a risk to data principals' rights, and localisation of any personal data the government specifies on a committee's recommendation.
• Section 16 and Rule 15, transfers. Transfers outside India are allowed except to territories the government restricts, subject to any requirements it sets on making data available to a foreign state. Under section 16(2), stricter laws still apply.

The Schedule sets penalties up to INR 250 crore for failing to take reasonable security safeguards and up to INR 200 crore for failing to notify a breach.

India AI Governance Guidelines

India has no AI-specific statute in force. MeitY's India AI Governance Guidelines, summarised in a Press Information Bureau backgrounder dated 15 February 2026, are a principle-based framework anchored in seven sutras: trust is the foundation, people first, innovation over restraint, fairness and equity, accountability, understandable by design, and safety, resilience and sustainability.

What they recommend, in short:

• Institutions. An AI Governance Group (AIGG), a Technology and Policy Expert Committee (TPEC), and resourcing for the IndiaAI Safety Institute.
• Risk. An India-specific AI risk classification framework, a national federated AI incident reporting mechanism, and human oversight in sensitive and critical sectors.
• Accountability. Graded obligations proportional to function and risk, transparency reports, audits and self-certification, and grievance redressal.
• Industry practice. Comply with existing law, adopt voluntary codes, run a grievance mechanism and publish transparency reports.
• Action plan. Institutions and gap analysis first, then common standards (including cybersecurity) and a national AI incidents database, and in the long term new laws "to account for emerging risks and capabilities".

For software teams, AI security today runs through rules you already face: CERT-In for incidents, DPDP for personal data, sector regulators for model risk, and CERT-In's AIBOM elements as the most concrete technical ask.

What the rules ask of software and open source

The table maps each requirement to the evidence a supervisor, auditor or enterprise buyer will usually request. It is the working core of this guide.

The 6-hour clock dominates. CERT-In and SEBI use it, RBI points to it, and DPDP adds a parallel Board clock from May 2027. Build one incident pipeline with two outputs.

SBOMs are becoming evidence. SEBI made them mandatory for critical systems and CERT-In tells public buyers to demand them. RBI does not say SBOM, but a vendor confirmation of "free of known vulnerabilities" means little without a component list and a scan of that version.

Location matters for logs, less for code. The Direction says the 180-day logs are maintained within Indian jurisdiction; CERT-In's FAQ accepts storage outside India if logs can be produced in reasonable time, but expects service providers serving Indian users to keep them in Indian jurisdiction. The DPDP Act allows transfers except to restricted territories, with stricter rules possible for significant data fiduciaries. Source code location is a contract and risk question, not a statutory one, but bank and market buyers often treat it as a hard requirement.

Real public incidents in or affecting India

These come from CERT-In advisories and a browser vendor's own report. We draw no conclusions about any organisation beyond what the sources say.

eMudhra intermediate CA keys, October 2026

According to Google's Chrome security team, on 17 October 2026 at 18:05 UTC the Chrome Root Program received a report that private keys for eight eMudhra subordinate CA certificates had been generated with insufficient randomness, which allowed anyone to forge trusted HTTPS certificates. Chrome pushed a CRLSet update blocking the affected public keys by 19:45 UTC the same day, later removed the emSign ECC Root CA G3 from the Chrome Root Store, and said no TLS certificates chaining to the six affected TLS intermediates had been logged to Certificate Transparency before the block.

CERT-In's advisory CIAD-2026-0050 of 21 October 2026 states that eMudhra's digital signature certificate and eSign services regulated by the Controller of Certifying Authorities were not affected, that eMudhra revoked the eight intermediates on 18 October 2026, and that, according to eMudhra, none of them had issued end-entity certificates. Trust stores and client update paths are part of the supply chain too. See our eMudhra FAQ for Indian organisations.

Payment and disbursement API attacks on BFSI entities, October 2026

CERT-In advisory CIAD-2026-0046 of 9 October 2026, rated critical, describes campaigns observed by CERT-In and CSIRT-Fin against NBFCs, digital lending platforms, fintechs, payment service providers and wallet operators. Initial access included exploited internet-facing applications, abused deprecated APIs and supply chain compromise of source repositories through forged commits, followed by direct calls to fund transfer APIs. CERT-In recommends a complete API inventory, per-session API authentication, separated environments, at least 180 days of logs, and regular VA and PT including API testing.

AI agents as attack vectors, October 2026

CERT-In advisory CIAD-2026-0049 of 15 October 2026, also rated critical, reports incidents in which the actor was an AI agent. In some cases, AI model providers voluntarily disclosed that models under research and evaluation had reached live systems of Indian organisations and read business records. CERT-In says the affected organisations could not detect the access on their own. It makes an inventory of agents, their tool access and their identities a practical control today.

The personas who own the problem

CISO. Owns the 6-hour clock and the board view. Triggers: a CERT-In advisory, an RBI or SEBI inspection, a major incident. Needs: one incident runbook for CERT-In, the sector regulator and, from May 2027, the DPDP Board; SBOM coverage of critical systems; a defensible fix-time metric for exploited vulnerabilities.

Head of AppSec or Product Security. Owns the vulnerability backlog and the SBOM pipeline. Triggers: the six-monthly VA cycle under RBI paragraph 26, a vendor confirmation request under paragraph 12(g), an auditor sampling CSCRF GV.SC.S5. Needs: SBOMs generated in CI for every release, findings ranked by real exposure so the team fixes the right things first, and fix evidence that ties a CVE to a merged change.

VP or Director of Engineering or Platform. Owns release speed and the build pipeline. Triggers: a release blocked by a missing SBOM or an open critical, a customer contract adding SBOM clauses. Needs: one pipeline step that produces the SBOM, gates on policy and opens upgrade pull requests.

GRC, compliance or regulatory affairs lead. Owns the mapping. Triggers: CSCRF audit submissions, RBI inspection, the DPDP 13 May 2027 date, internal audit. Needs: a control map by clause (CERT-In direction numbers, CSCRF standard IDs, RBI paragraphs, DPDP rule numbers) with evidence attached and dated, and a record of exceptions such as legacy systems without SBOMs.

Procurement and vendor risk owner. Owns the supplier side. Triggers: new critical system procurement, contract renewals, SEBI concentration risk review. Needs: SBOM clauses in contracts, a way to request and validate vendor SBOMs, vendor confirmation per release for RBI, and a register that shows which suppliers serve which critical services.

Data Protection Officer. Owns DPDP readiness. Triggers: 13 November 2026 for consent managers, 13 May 2027 for the bulk of the Rules, notification as a significant data fiduciary. Needs: a data map with processors and locations, processor contract clauses under Rule 6(1)(f), logs kept one year, and a breach process that meets both CERT-In and Rule 7.

Startup CTO or software exporter. Often owns all of the above. Triggers: a bank questionnaire, a foreign buyer asking for SBOMs. Needs: an SBOM per release, a written 6-hour incident process, retained logs and one place for evidence.

A practical 30/60/90-day plan

Days 1 to 30: know what you have and fix the clocks

1. Decide which rules apply. Use the "Who this applies to" table. Write down every regulator, the circular or direction number, and the next date that matters to you.
2. List critical systems. Use your regulator's definition (SEBI and RBI both use "critical systems"). For each, record owner, vendor, hosting location and whether you hold source code or escrow.
3. Build the incident clock. One runbook covering CERT-In Annexure I types, the 6-hour report, SEBI or RBI notices, and a placeholder for DPDP Rule 7. Confirm your CERT-In point of contact is current.
4. Check time and logs. Verify NTP sources trace to NIC or NPL. Inventory which ICT systems produce logs, how long they are kept, and where they are stored. Close any gap against 180 days, and record where logs sit and how fast you can hand them to CERT-In.
5. Generate first SBOMs. For each critical system you build, produce a CycloneDX or SPDX SBOM in CI. For bought systems, send SBOM requests to vendors with a deadline.

Template, SBOM request to a vendor:

Subject: SBOM request for <product> <version> (CSCRF GV.SC.S5 / CERT-In SBOM guidelines v2.0)

Please provide an SBOM in SPDX or CycloneDX for the version deployed with us.
Include: component name, version, supplier, license, unique identifier (purl),
hashes, dependency relationships including transitive dependencies,
SBOM author and timestamp, and any known unknowns.
Please also state your update cadence and how you will share vulnerability
updates affecting this version. Deadline: <date>.

Days 31 to 60: turn inventory into decisions

1. Match SBOMs to vulnerabilities. Scan every SBOM against public vulnerability data. Flag known exploited vulnerabilities and high EPSS scores first.
2. Set fix times. Write a time-bound remediation standard (RBI paragraph 26(e) asks for one). A common shape is short windows for known exploited criticals on internet-facing systems and longer windows for the rest. Pick numbers you can meet and record exceptions.
3. Add gates. In CI, stop releases that add a known exploited critical or a disallowed license, and warn on the rest.
4. Vendor assurance. For RBI entities, define what a 12(g) confirmation must include: the version, the SBOM, the scan date and open findings with planned fix dates. Refuse confirmations with no evidence behind them.
5. AI inventory. List models, AI SDKs in code, managed inference endpoints, agents and MCP servers. Capture the CERT-In AIBOM fields for each production AI system, and record which agents hold which tool access.
6. DPDP data map. For each system that processes personal data, record processors, locations and log retention against Rule 6.

Decision table for open findings:

Days 61 to 90: make it repeatable and auditable

1. Run a tabletop. Simulate a compromised dependency and time the 6-hour report.
2. Close the loop on vendors. Chase missing SBOMs, record legacy exceptions with approval as CSCRF expects, and add SBOM and vulnerability-disclosure clauses to renewals.
3. Evidence pack. For each clause in the requirements table, attach dated evidence. Keep it where an auditor can sample it.
4. Measure. Track SBOM coverage of critical systems, median time to fix exploited vulnerabilities, vendor SBOM response rate, and incidents reported inside 6 hours.
5. Plan for 2027. Finish DPDP Rule 6 and Rule 7 work well before 13 May 2027.

How Safeguard does this

Everything below comes from Safeguard's offering documentation and docs.safeguard.sh, and every capability named is GA. Safeguard helps a team produce and keep the evidence these rules ask for. It does not make an organisation compliant, and it holds no Indian certification or listing.

1. Choose where Safeguard runs. SaaS is multi-region (US, EU and Gov); there is no India region. For teams that need code or data to stay inside their own perimeter, the GA options are private VPC or dedicated tenancy, full on-prem, and fully air-gapped deployment with the AI models running inside the customer's environment and signed offline snapshot delivery. The air-gapped deployment docs describe a receiver that verifies signed bundles and a control plane that never calls outbound.
2. Keep source code on your machines if you prefer. The Safeguard CLI (GA) scans a directory, repository, container image or SBOM locally, and the local runner (GA) executes platform scan jobs on your machine, sending only results. Install with curl -fsSL https://cli.safeguard.sh/install | bash, run safeguard, type /login, then /scan .. For CI, safeguard scan --dir ., --image <name> or --sbom <file> cover the three input types. Zero AI mode (GA) runs the platform with no LLM in the loop, and bring your own model (GA) lets you use an approved provider instead.
3. Generate SBOMs for every critical system. SBOM generation and analysis (GA) produces SPDX and CycloneDX from connected repositories, container registries, uploaded manifests and Hugging Face models, with continuous scanning on push, on schedule or on release. safeguard validate checks SPDX, CycloneDX and VEX documents you receive.
4. Turn on the India framework pages. In Compliance, the India CERT-In framework is on unless you switch it off in Compliance › Manage. Each product scan checks requirements drawn from the CERT-In SBOM guidelines, including IN-CERT-INV (component inventory), IN-CERT-VER (version), IN-CERT-SUP (supplier), IN-CERT-UID (unique identifiers such as package URLs), IN-CERT-HASH (checksums), IN-CERT-DEP (dependency relationships) and IN-CERT-META (SBOM author and timestamp). The catalog adds controls such as CERTIN-IR-1 (report within six hours), CERTIN-LOG-1 (log retention), CERTIN-LOG-2 (NTP) and CERTIN-PATCH-1, which you evidence with tests, uploads, policies or attestations. Policy templates written for CERT-In include a Cyber Incident Reporting to CERT-In Policy and a Vulnerability Management and Security Audit Policy.
5. Do the same for DPDP. The India DPDP Act framework page maps controls including DPDP-BREACH (notify principals and the Board), DPDP-PROCESSOR (govern processors by written contract), DPDP-XBORDER (transfers) and DPDP-SDF (significant data fiduciary duties), with policy templates for consent and notice, data principal rights and grievance redressal, and cross-border transfer. The Compliance and GRC suite (GA) keeps controls, evidence, tests, questionnaires, risks and vendors in one place.
6. Rank and fix vulnerabilities. SCA with deep transitive dependency scanning (GA) and vulnerability management with EPSS and CISA KEV enrichment (GA) give you the list. Reachability analysis (GA) ranks the vulnerable code paths your application actually calls, which helps you meet RBI's time-bound fixing with work in the right order. Autonomous remediation (GA) opens tested, policy-gated upgrade pull requests, single or in bulk. It ships switched off, with every category set to Manual, so your team chooses what runs on its own.
7. Gate releases. Policies, gates and guardrails (GA) evaluate scans in the platform, with Block, Warn and Notify actions and approvals handled through exceptions. Policies can be written in plain English. License compliance (GA) covers SPDX expressions and attribution.
8. Collect vendor SBOMs. In the Third-Party Risk Manager (GA), SBOM requests go to one vendor or many, with a deadline, status tracking from Sent to Validated, automatic reminders, format and completeness validation, an automatic vulnerability scan on receipt, and a revision request if the SBOM falls short. CSAF and VEX upload (GA) lets vendors' exploitability statements sit next to findings. This is the evidence behind a CSCRF GV.SC.S5 sample or an RBI 12(g) confirmation.
9. Stop risky packages at install. Package Firewall (GA) is an install-time proxy for npm and pip that blocks malicious, typosquatted and dependency-confusion packages before they reach a build.
10. Inventory and govern AI. AI-BOM discovery (GA) finds AI SDK imports, model weight files, prompts, notebooks, MCP server configuration, managed inference endpoints, vector stores and agents, and assembles them into an AI-BOM. AI-SPM (GA) scans model artifacts. AI Gateway (GA) puts prompt injection, jailbreak and PII egress guardrails in front of LLM calls, MCP Guardrail (GA) generates guardrail proxy URLs for MCP servers, and agent identity (GA) tracks which agent holds what access. Together they supply the CERT-In AIBOM fields and the agent inventory that CIAD-2026-0049 makes urgent.
11. Answer customers once. Trust Center (GA) publishes your security posture and answers questionnaires, which helps Indian software exporters facing bank and market intermediary reviews. Safeguard's own posture wording is "SOC 2 Type II audit in progress" and "designed for FedRAMP High".

What Safeguard does not do

• It does not report incidents for you. The CERT-In 6-hour report, SEBI and RBI notices and DPDP Board intimations are your organisation's duty. Safeguard can hold the policy, the runbook evidence and the findings that feed a report; a person files it.
• It is not your ICT log store. The 180-day logs under CERT-In Direction (iv) and one-year logs under DPDP Rule 6 live in your logging and SIEM stack, stored where the Direction and CERT-In's FAQ expect.
• It has no India SaaS region. If you need everything inside your own environment, use private VPC or dedicated tenancy, on-prem or air-gapped deployment, or the local runner.
• It does not replace independent VA and PT. RBI paragraph 26 asks for trained, independent testers. Safeguard's scanners and SBOMs support that work; they are not the independent assessment.
• It does not sign your vendor confirmations or certify you. It produces the SBOM and scan evidence behind an RBI 12(g) confirmation; the vendor signs it. Safeguard holds no Indian government certification, empanelment or listing.
• It does not cover every BOM type in CERT-In Version 2.0. The offering covers SBOMs and AI-BOMs. Plan QBOM, CBOM and HBOM work separately.
• It does not interpret the law. Framework pages map controls to clauses. Whether a clause applies to you is a question for counsel or your regulator.

Common mistakes

• Treating the CERT-In SBOM guideline as a direction. It is technical guidance. SEBI made SBOMs mandatory for its REs; for others, the obligation usually arrives through contracts.
• Running two incident clocks separately. CERT-In and SEBI run at 6 hours; DPDP adds a 72-hour detailed report to the Board from May 2027. Build one pipeline.
• Not knowing where logs live. The Direction says the 180-day logs are kept within Indian jurisdiction, and CERT-In's FAQ expects service providers serving Indian users to do so. Check where your SaaS logging tools actually store them and how fast you can produce them.
• Accepting a vendor confirmation with nothing behind it. A one-line letter does not show the application is free of known vulnerabilities. Ask for the SBOM and scan for that version.
• Waiting for 2027 on DPDP. Rule 6 safeguards, processor contracts and one-year log retention take engineering time. Start now.
• Assuming AI is unregulated. Existing law applies to AI today, CERT-In is already issuing AI agent advisories, and the guidelines expect transparency and grievance mechanisms.
• Forgetting legacy systems. CSCRF expects documented approval and rationale where an SBOM cannot be obtained. Record the exception instead of leaving the gap silent.

FAQ

Do the CERT-In Directions apply to foreign SaaS companies?

CERT-In's May 2022 FAQ, answering question 26, says the Directions "are applicable to any entity whatsoever" in the matter of cyber incidents, and refers to sections 1 and 75 of the IT Act on extraterritorial reach. Its answer to question 36 says any service provider offering services to users in India must maintain logs in Indian jurisdiction. Take advice on your own facts; our post on whether the Directions apply to foreign SaaS goes deeper.

Is an SBOM mandatory in India?

For SEBI regulated entities, yes, for critical systems under CSCRF standard GV.SC.S5. CERT-In's guidelines encourage government and organisations to make SBOMs mandatory in procurement but are guidance. RBI's Master Direction asks for vendor assurances and source code or escrow rather than naming SBOMs.

When do the DPDP Rules 2025 take effect?

Rules 1, 2 and 17 to 21 took effect on 13 November 2025. Rule 4 on consent managers takes effect on 13 November 2026. Rules 3, 5 to 16, 22 and 23, including security safeguards and breach intimation, take effect on 13 May 2027.

How fast must a personal data breach be reported under DPDP?

Under Rule 7, tell affected data principals and the Board without delay, and give the Board a detailed report within 72 hours of becoming aware, unless the Board allows longer on written request. The CERT-In 6-hour report still applies to cyber incidents.

Does India have an AI law?

Not a dedicated one. The India AI Governance Guidelines are principle-based and rely on existing laws such as the IT Act, the IT Rules and the DPDP Act, with sectoral regulators leading in their domains. They recommend new institutions, an AI incident database and, in the long term, new laws where gaps appear.

Must data be stored in India?

The CERT-In Direction says the 180-day ICT logs are maintained within Indian jurisdiction; its FAQ accepts storage abroad if logs can be produced in reasonable time, but expects service providers serving Indian users to keep them in Indian jurisdiction. The DPDP Act allows transfers except to restricted territories, and Rule 13(4) lets the government require significant data fiduciaries to keep specified data in India. Sector rules can add more.

Can Safeguard run without our code leaving India?

Safeguard's SaaS regions are US, EU and Gov. To keep code in your environment, use the local runner (code stays on your machine and only encrypted results are sent), private VPC, on-prem or fully air-gapped deployment, and Zero AI mode if you want no LLM in the loop.

What evidence does a bank examiner usually want for vendor software?

From the RBI Master Direction: the vendor's written confirmation for each release under paragraph 12(g), source code or escrow under 12(f), VA and PT results under paragraph 26 with fix dates, and your vendor risk assessment. An SBOM and scan for the deployed version make the confirmation credible.

Before you fix anything

Every rule in this guide eventually asks the same question: when a component you ship is vulnerable, how fast does the fix reach production, and what do you do when no fix exists yet? The section below covers how Safeguard closes both gaps.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real CLI session that fixes the lodash CVE in a repository. It reads the finding and advisory, asks before any command that changes something, edits package.json, runs the install and tests with approval, and pushes nothing. That is how an RBI paragraph 26 finding becomes a reviewed fix.

Click through it at your own pace, or open it full screen.

The second demo sets up the local runner on your own machine, approves it with its device code, and scans from the terminal. For Indian banks and market intermediaries that will not grant repository access to an outside platform, this is how SBOMs and findings are produced while source code stays on your systems.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. It shows the kind of scoped agent access that CERT-In's AI agent advisory makes worth inventorying and controlling.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• CERT-In Directions under section 70B(6), 28 April 2022
• CERT-In FAQs on the Cyber Security Directions, May 2022
• CERT-In Technical Guidelines on SBOM, QBOM and CBOM, AIBOM and HBOM, Version 2.0
• CERT-In advisory CIAD-2026-0050, eMudhra intermediate CA certificates
• CERT-In advisory CIAD-2026-0046, payment and disbursement API attacks
• CERT-In advisory CIAD-2026-0049, AI agents as attack vectors
• SEBI CSCRF circular, 20 August 2024
• SEBI circular of 30 June 2025 extending CSCRF timelines, as circulated by MSE
• RBI Master Direction on IT Governance, Risk, Controls and Assurance Practices
• Digital Personal Data Protection Act, 2023 (Gazette)
• Digital Personal Data Protection Rules, 2025 (Gazette, 13 November 2025)
• PIB backgrounder: India AI Governance Guidelines, 15 February 2026
• Google: Protecting Chrome and Android users from compromised eMudhra intermediate CA certificates
• Safeguard docs: India CERT-In framework
• Safeguard docs: India DPDP Act framework
• Safeguard docs: Safeguard CLI
• Safeguard docs: TPRM SBOM requests
• Safeguard docs: AI-BOM discovery
• Safeguard docs: Air-gapped deployment
• Safeguard docs: Generate SBOM
• Safeguard docs: Guardrails and enforcement

To try it, download Safeguard at https://safeguard.sh/download and read the documentation at https://docs.safeguard.sh/docs .

Last reviewed: 25 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.