> For the complete documentation index, see [llms.txt](https://docs.veedna.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.veedna.com/sca360-flexible-deployment-for-data-center-cloud-integrated-environments/bajaj-finances-cicd-integration-sept-2026.md).

# 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.

{% hint style="info" %}
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.
{% endhint %}

## 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:

{% code overflow="wrap" %}

```yaml
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"
```

{% endcode %}

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.

{% hint style="info" %}
**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.
{% endhint %}

## 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:

{% code overflow="wrap" %}

```yaml
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"
```

{% endcode %}

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](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/about-githubs-ip-addresses) (the `hooks` list from `https://api.github.com/meta`) and [Azure DevOps inbound connections](https://learn.microsoft.com/en-us/azure/devops/organizations/security/allow-list-ip-url) (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](https://docs.github.com/en/webhooks/using-webhooks/creating-webhooks)); on Azure Repos, membership of Project Administrators or Project Collection Administrators ([Azure DevOps docs](https://learn.microsoft.com/en-us/azure/devops/service-hooks/services/webhooks)).

### At a glance

<table><thead><tr><th width="180"></th><th>Option 1 — Webhooks</th><th>Option 2 — Azure Blob Trigger File</th><th data-hidden>Option 3 — In-line CLI</th></tr></thead><tbody><tr><td>Where the scan runs</td><td>Bajaj VM</td><td>Bajaj VM</td><td>CI/CD runner</td></tr><tr><td>Change per repository</td><td>Webhook config only (org-wide on GitHub, per project on Azure Repos)</td><td>Pipeline step that writes a file</td><td>Workflow file that runs the scan</td></tr><tr><td>Network direction</td><td>Inbound to the VM required</td><td>Outbound only</td><td>Outbound from the runner</td></tr><tr><td>Secrets required</td><td>Webhook secret + Git PAT on the VM</td><td>Blob identity + Git PAT on the VM</td><td>Lineaje PAT in each repo / org</td></tr><tr><td>Artifactory credentials</td><td>On the VM (already configured)</td><td>On the VM (already configured)</td><td>On every runner</td></tr><tr><td>Trigger latency</td><td>Immediate</td><td>Next polling cycle</td><td>Immediate, inside the build</td></tr></tbody></table>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.veedna.com/sca360-flexible-deployment-for-data-center-cloud-integrated-environments/bajaj-finances-cicd-integration-sept-2026.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.