Claude 
Cursor 
Codex 
Hugging Face 
NVIDIA 
Visual Studio Code 
Devin 
Kiro 
Open Code 
NanoClaw 
Docker 
npm 
PyPy 
Wiz 
Financial Services 
Gaming 
Public Sector 
Automotive 
Technology 
Healthcare 
Prove CERT-In Compliance Continuously
The Indian Computer Emergency Response Team (CERT-In) gives you 6 hours to report from the moment you detect an incident. With JFrog, your evidence is ready before that clock starts.
The Cost of Getting CERT-In Wrong
Financial: Fine of Up to ₹1 Crore
You have 6 hours to report an incident to CERT-In. Non-compliance with CERT-In directions can carry a fine of up to ₹1 crore.
Business: No Government Contract
Government contracts require SBOM coverage as a condition of award. An incomplete SBOM disqualifies the bid and your standing in every review cycle that follows impacting current and future business.
Personal: Liability for Executives
When a company breaches a CERT-In direction, the executives in charge are also subject to scrutiny and can face up to one year in prison, unless they prove they exercised due diligence.
Your Current Processes Leave Three Gaps CERT-In Will Expose
Your SBOM Stops at Build Time
Your build-time SBOM captures one snapshot. It reveals nothing about software running in production months later. CERT-In guidelines recommend a living component record across the entire lifecycle of software being deployed.
Your Incident Records Live in Logs, Not Reports
Your evidence sits in scattered tools. Your 6-hour reporting window becomes a frantic search. CERT-In’s window keeps running while your team hunts through disconnected logs, reducing the likelihood of complete evidence.
Your Third-Party and Fourth-Party Software Has No SBOM
Your source code scanners see only the code you write. CERT-In requires a complete SBOM for your entire supply chain. That includes vendor software and pre-compiled binaries that ship without source code, whether built by humans or AI. You cannot scan what you cannot inventory. An auditor can find that blind spot before you do.
CERT-In Requirements, Mapped to JFrog Capabilities
JFrog is a System of Record with a governance layer built in, so each requirement below ties to evidence.
SBOM Generation and Component Documentation
Standards-based SBOM covering all components, dependencies, licenses, hashes, and provenance across every release
Continuous SBOM per Release
JFrog can generate a CycloneDX or SPDX SBOM for every release, covering component identity, license, dependency graph, cryptographic hashes, and build provenance, with evidence attached to the release record.
Vulnerability Handling and VEX
Continuous vulnerability monitoring, exploitability assessment, and traceable remediation records across the full product lifecycle
Continuous Monitoring and Release Gating
JFrog can continuously monitor components for known vulnerabilities, rank findings by exploitability, and gate releases so nothing ships with an unresolved critical CVE unless a policy exception explicitly allows it.
Incident Evidence and Reporting Records
Audit-ready evidence assembly for the 6-hour incident report and subsequent CERT-In notifications, drawn from continuous scan and remediation history
Ready-Made Evidence for Reporting
JFrog can keep scan history and remediation records attached to each release, so when an incident fires, your team pulls existing evidence for the 6-hour report instead of reconstructing it from disconnected logs.
SDLC Policy Gates and Third-Party Screening
Policy enforcement at every SDLC stage, with due diligence on every open-source and third-party component before it enters a build
Policy-Based Component Screening
JFrog can enforce policy gates at ingestion, PR, build, and release promotion, blocking vulnerable or unlicensed components before they reach production and logging every decision for audit.
Third-Party and Binary Software Coverage
SBOM and vulnerability coverage for third-party applications, pre-compiled binaries, and vendor-supplied software where no source code is available.
Binary Scanning Without Source Code
JFrog can scan any binary or container stored in Artifactory, including compiled JARs, Docker images, and firmware, and generate an SBOM (with VEX data) for procured software where the vendor provides none.
Supply Chain Provenance and Build Traceability
Traceable provenance from source to build to artifact, with dual-timestamp records for audit-grade chain of custody
Build-Info Chain of Custody
JFrog can capture CI agent identity, VCS commit, artifact hashes, and deploying principal for every build, producing a provenance record that ties each artifact to its origin.
SBOM Governance and Access Control
Role-based access control and SBOM lifecycle governance supporting public and private SBOM distribution as defined in CERT-In Section 5.3
RBAC and SBOM Distribution Controls
JFrog can enforce role-based access to SBOM data and vulnerability findings, supporting the public and private SBOM model CERT-In Section 5.3 defines, without exposing sensitive supply chain data beyond authorized teams.
From CERT-In Guidelines to Automated Enforcement and Evidence-based Releases with JFrog AppTrust
Block Non-Compliant Releases Before They Ship
Automated policy gates evaluate every promotion across PR, build, and release. Any build with unresolved CVEs, missing SBOM fields, or undeclared components is blocked before reaching production.
Pull Complete Evidence for Any Release, Instantly
AppTrust automatically binds SBOMs, VEX, test results, and provenance into a single signed record as you build. When auditors ask, complete release evidence is instantly ready. No manual assembly of spreadsheets or screenshots is required.
Frequently Asked Questions
CERT-In obligations under the Information Technology Rules apply to service providers, intermediaries, data centres, body corporates, and government organizations operating in India, including operators of critical information infrastructure. The 2022 directions expanded the scope to cover service providers, data centers, and body corporates operating in India, with a 6-hour window to report incidents from the moment of detection. If your organization processes data, operates systems, or delivers services in India, CERT-In obligations apply to you.
Yes. CERT-In obligations apply based on where you operate and deliver services, not where your organization is incorporated. If your organization offers services to users in India, CERT-In reporting requirements extend to you.
JFrog AppTrust keeps scan results, remediation history, and policy sign-offs attached to each release continuously. When an incident fires, your team starts the 6-hour report from records that already exist, not from a reconstruction that starts after the alert. Your team still drafts and submits the report to CERT-In. JFrog provides the evidence that makes that process fast.
JFrog can generate standards-based SBOMs in CycloneDX and SPDX formats that cover the core mandatory data fields CERT-In defines. Some fields require organizational input, such as component criticality and usage restrictions, which no automated scanner can supply. JFrog captures those through structured Artifactory Property Sets that your security and legal teams control. One field, end-of-life date, remains an industry-wide gap across all SCA tools, not specific to JFrog.
JFrog is not a CERT-In certification body and does not issue compliance certifications. CERT-In obligations sit with your organization as the operator or service provider. JFrog provides the software supply chain visibility, SBOM generation, vulnerability intelligence, policy enforcement, and evidence chain that support your compliance program. Your team owns the compliance posture. JFrog builds the audit trail.
CERT-In Technical Guidelines v2.0 define mandatory data fields that go beyond what a standard CycloneDX or SPDX baseline export provides. The additional requirements include component criticality, usage restrictions, release date, end-of-life date, and SBOM author identity. Some fields require organizational judgment that no automated scanner can supply. JFrog covers the fields that scanning addresses and provides structured mechanisms for your team to supply the fields that require human input.
Yes. CERT-In guidelines recommend an SBOM for every software component in your supply chain, including open-source libraries, third-party dependencies, and COTS binaries. The obligation covers both software your organization develops and software it procures. JFrog Xray scans open-source components natively and generates a standards-based SBOM without requiring access to source code, which matters most for procured binaries where the vendor does not provide an SBOM.
The JFrog Platform holds your software artifacts and the governance layer in one System of Record, creating a Single Source of Truth. Curation, scanning, provenance, VEX, and release governance feed the same SBOM, from code to production. This allows teams to answer an auditor from one source vs. having to collect information from scattered tools. This reduces the time to respond and increases the completeness of the response.
