Bajaj Finances - CICD Integration - Sept 2026

Options and pre-requisites for integrating SBOM360 scans into Bajaj Finances CI/CD pipelines.

This page captures where the Bajaj Finances integration stands today, what is still open, and the three options available for triggering SBOM360 scans from CI/CD.

The options below deliberately describe what each option is and what it requires. They do not include setup steps. Once Bajaj Finances picks an option the documentation will be provided in full.

Current Context

Source-code scanning today runs off a scheduled script on the SCA360 VM, driven by a config file that sits alongside the Lineaje CLI.

Each source-code block in that config file names a repository, the branches to watch, the Lineaje organization to file results under, and the project type:

supported_orgs:
  - Root Organization

source-code:
  - org-name: "Root Organization"
    project: "xxx"
    discovery-logic: "git"
    repository-url: "https://dev.azure.com/example-org/example-project/_git/example-repo"
    branch:
      - main
    type: "npm"

On each cycle the script shallow-clones every configured branch, reads the latest commit timestamp, and scans only those branches with commits in the last 15 days. The scan runs on the VM using the Lineaje CLI.

This is a pull model: a new repository or branch is onboarded by editing the config file.

For manual triggers, the current script will continue to exist.

Whichever option below is selected, it is additive. The existing script and its config file stay in place for on-demand and scheduled scans, and for any repository that is not wired into CI/CD.

Open Questions

These need answers from Bajaj Finances before an option can be recommended.

1. When does the CI/CD integration get triggered? On every push to any branch, on merges to main / release branches only, on pull request creation, at a specific build or release stage, or on a nightly schedule for repositories that changed?

2. How many repositories and branches are in the first phase, and what is the expected steady-state scan volume per day?

3. Organization / group mapping — should every repository file results under a single Lineaje organization, or does each application map to its own group?

Options

Option 1 - Azure Blob Trigger File

Description

At the end of a build, the CI/CD pipeline writes a small metadata YAML file into a dedicated Azure Blob container. The script on the VM polls that container on its schedule, picks up any file it has not already processed, reads the scan parameters from it, and runs the scan. Files already processed are recorded so a trigger file is never scanned twice.

The trigger file is the contract between the pipeline and Lineaje:

metadata:
  group: "Root Organization"
  project: "example-project"
  repository-url: "https://dev.azure.com/example-org/example-project/_git/example-repo"
  matching-ref: "main"
  type: "npm"

The pipeline never runs a scan itself — it only drops a file. All scanning, and therefore all artifactory and Lineaje network access, stays on the VM where it is already configured.

Pre-requisites

• An Azure Storage account and a blob container dedicated to trigger files.

• A VM to run the script — the existing SCA360 VM is sufficient. Outbound access only; no inbound network access is required.

• Access to the container at both ends — the VM needs read access (a managed identity or service principal granted Storage Blob Data Reader, or equivalent), and the pipeline needs write access (a pipeline identity, service connection, or SAS token scoped to that container).

• A Git clone token (PAT) held on the VM, with read access to the repositories being scanned.

• A pipeline change in each repository — a step at the end of the build that writes the metadata YAML file to the container.

Option 2 - Webhooks

Description

The source control system sends a webhook on every push. A listener service running on a Lineaje VM verifies the delivery signature, queues the job, and runs a scan with the Lineaje CLI against the repository and branch named in the payload.

This inverts the current model. There is no config file enumerating repositories and branches, and no commit-date comparison — the webhook delivery is the "something changed" signal, and the payload already carries the repository URL and branch. Onboarding a repository is a webhook configuration in the source control system, with no change to that repository's build pipeline.

On GitHub, a webhook is configured per repository or once at the organization level. On Azure Repos the equivalent is a service hook subscription, configured per project.

Pre-requisites

• A host for the listener — an always-on Linux VM running the listener service, with the Lineaje CLI installed and registered. This can be the existing SCA360 VM.

• Inbound network access — GitHub and Azure Repos must be able to reach the listener. This is the significant constraint: both are cloud-hosted, so if the listener sits inside the Bajaj network an inbound path has to be opened — a reachable address, firewall rule, reverse proxy, or tunnel. Both publish the source ranges to allow: GitHub IP addresses (the hooks list from https://api.github.com/meta) and Azure DevOps inbound connections (published per geography, or allowed as the AzureDevOps service tag).

• An HTTPS endpoint for the listener. Azure Repos only delivers to HTTPS, and will not deliver to a loopback or special-range address. The webhook secret protects payload authenticity, not confidentiality.

• A webhook shared secret, configured identically on the webhook and on the listener, so deliveries can be signature-verified.

• A Git clone token (PAT) held on the listener host, with read access to every repository it will scan. One token per source control system.

• Permission to create the webhook — on GitHub, repository admin for a single repository or organization owner for an org-wide webhook (GitHub docs); on Azure Repos, membership of Project Administrators or Project Collection Administrators (Azure DevOps docs).

At a glance

	Option 1 — Webhooks	Option 2 — Azure Blob Trigger File
Where the scan runs	Bajaj VM	Bajaj VM
Change per repository	Webhook config only (org-wide on GitHub, per project on Azure Repos)	Pipeline step that writes a file
Network direction	Inbound to the VM required	Outbound only
Secrets required	Webhook secret + Git PAT on the VM	Blob identity + Git PAT on the VM
Artifactory credentials	On the VM (already configured)	On the VM (already configured)
Trigger latency	Immediate	Next polling cycle