Open source process: From use to distribution

1. What we do in this chapter

This chapter documents the approval of open source use, the pre-release checklist, and the vulnerability response procedures. If a policy defines "what should be done," a process defines "how it is done." Even if the policy states "using AGPL requires a source disclosure review," the policy remains a declaration unless you decide who reviews it, when, and in what form.

Work with the agents/en/04-process-designer agent to generate 5–7 deliverables tailored to your company's environment. You also cover CI/CD integration, aiming for a sustainable system that is naturally embedded in the development flow.

2. Background knowledge

tip

Unfamiliar acronyms such as SBOM, CVE, and CVSS are explained in plain language in the Glossary.

tip

Detailed explanations of each step, along with real corporate examples, are available in the KWG Open Source Guide — Process. This chapter's structure and requirement descriptions are reworked from that KWG guide (CC BY 4.0).

The overall open source lifecycle flow

Once you see the full flow of a single open source component entering and leaving the codebase, it becomes clear where and what kind of process is needed.

Approval on adoption, a checklist before distribution, and CVE response during operation — you document this flow as the six core processes below.

The 6 core processes

3-1. Open source usage approval process

When adopting new open source, proceed in order: check the license, check for vulnerabilities, then obtain approval from the program manager. If you define an allowed-license list (allowlist) in advance, licenses on the list are approved automatically, minimizing the impact on development speed.

Category	Criteria	Handling
Allowed	On the allowed-license list, no known Critical CVEs	Automatic approval
Conditionally allowed	Copyleft license, or has a High CVE	Approval after program manager review
Prohibited	Non-commercial license, or unpatched Critical CVE	Use prohibited

Pre-flight ingest gate — developers see only what is verified

Instead of judging each approval after the fact, many teams enforce it through repository structure. Rather than pulling directly from public repositories (npm, PyPI, etc.), you first ingest into an internal repository while checking license, vulnerabilities, and source integrity, and register only versions that pass. Developers and CI see only the verified internal repository, which cuts off the entry path for supply chain attacks such as dependency confusion and typosquatting.

Public repo → [checks: license, CVE, integrity, provenance] → register in internal repo on pass → developers and CI use internal only

Build the internal repository on an artifact repository such as Nexus or Artifactory, and wire the check step to the scanning in 5.3 Vulnerability Analysis and Response.

The integrity check confirms that the file you received is the one that was published (hashes match). Provenance verification adds one more layer on top. Check the SLSA provenance attestation or signature attached to the package (npm provenance, Sigstore and similar), match it against which workflow in which repository produced the artifact, and hold registration when there is no attestation or it points somewhere other than the repository you expected. For securing the publish path itself, see the publish and install path section of Software Composition Analysis (SCA).

Signature verification alone is not enough, though. An attestation only guarantees that the build came out of the declared pipeline; it does not cover a compromise of that pipeline. In Mini Shai-Hulud in 2026-05, 84 malicious packages were published carrying valid SLSA Build Level 3 attestations. Use provenance verification as one axis of the gate, and keep license and vulnerability checks plus post-ingest monitoring alongside it.

3-2. Pre-release compliance check

Be sure to check the items below before distributing the software externally. If it does not pass this checklist, distribution does not proceed.

Check that the SBOM has been updated recently (last update date)
Check that the NOTICE file is included
Confirm fulfillment of the source code disclosure obligations of copyleft licenses (the obligation to release derivative works under the same license)
Verify that the review of licenses not on the allowed-license list has been completed

Automatic attribution notice generation — onot

Writing the pre-release attribution notice (NOTICE) by hand often leads to omissions. onot is a tool that takes an SBOM (an SPDX or CycloneDX document) as input and automatically generates the OSS attribution notice (co-developed by Kakao and SK Telecom). You can feed in the SBOM created in the previous step and automate attribution notice writing.

3-3. Vulnerability response process

With an SBOM, you can quickly check whether your software is affected when a new CVE is released. You use resources efficiently by applying different response deadlines based on CVE severity (CVSS score).

Canonical response deadlines

The CVSS-severity response-deadline table (the KWG baseline plus a stricter organizational SLA option) and the VEX concept are consolidated in Vulnerability response deadlines and VEX. The process deliverable vulnerability-response.md documents these as your company SLA.

Check the separate reporting obligation if you ship into the EU market

Separately from the response deadlines above, the EU CRA requires reporting an exploited vulnerability or a severe incident to regulators (CSIRT and ENISA) within 24 hours for the early warning and 72 hours for the notification, applying from 2026-09-11. This applies only to organizations placing products with digital elements on the EU market. For the detailed deadlines and reporting channel, see the EU CRA section of Vulnerability response deadlines and VEX; for the deliverable, see §9 of vulnerability-response.md.

3-4. Open source contribution process (§3.5.1)

ISO/IEC 5230 §3.5 requires separate policies and procedures for engaging with open source communities (contribution and disclosure). Even organizations with no plans to contribute or disclose need a policy document stating "not currently applicable."

This is the process of contributing code, documentation, and bug reports to external open source projects.

Key things to check when contributing:

IP protection: Legally confirm that your contributions do not include company confidential information, patented technology, or third-party IP.
CLA handling: Verify and record whether the Contributor License Agreement has been signed.
Approval stage: Obtain approval from the open source program manager and team lead before contributing (apply differently depending on the size of the contribution).
Contribution history: Record the contribution history (project, details, contributor, date) in an internal log.
AI tool policy check: Before contributing code generated or assisted by an AI coding tool, check the upstream project's AI contribution policy in advance.

Upstream AI contribution policies diverge:

The same patch may only need to be disclosed in one project and be rejected outright in another. That is why you must read the target repository's contribution guide and PR template before you send anything.

Project	Approach	What it requires
Linux kernel	Disclosure required	An `Assisted-by: AGENT_NAME:MODEL_VERSION` trailer naming the tool and model version. AI agents must not add `Signed-off-by`, because only a human can certify the Developer Certificate of Origin (DCO)
QEMU	Declined	Contributions believed to include or derive from AI-generated content are declined. Using AI for research, static analysis, and debugging is allowed as long as its output does not end up in the patch
MicroPython	Declaration required	The PR template has a "Generative AI" section that every contributor must answer. If AI was used, the contributor states that a human checked the code and takes responsibility for it

Sources: the Linux kernel coding assistants document, QEMU code provenance, and the MicroPython PR template.

Put "check the target project's AI policy" into your internal procedure as a step before approval, and record both the result of that check and whether AI tools were used in the contribution log. If a policy violation surfaces after approval, you have to withdraw a patch you already submitted.

3-5. Internal project disclosure process (§3.5.1)

This is the process of releasing internally developed software as open source.

Key things to check before disclosure:

IP clearance: Ensure the released code is free of third-party IP, customer data, and company secrets.
License selection: Determine the open source license to apply to the software being released (MIT, Apache-2.0, etc.).
Security scan: Scan for vulnerabilities and hard-coded credentials before disclosure.
Approval stage: Final approval from the CTO or a designated committee.

If you have no plans to contribute (3-4) or disclose (3-5), the agent does not generate those documents, and the gap analysis treats those items as N/A. If you wish, you can still write a declarative document yourself stating "No current plan — this procedure will be followed once a plan is made."

3-6. External inquiry response process (§3.2.1)

This is the channel and procedure for receiving open-source-related inquiries from outside — customers, the community, or license holders. It consists of a published intake channel (email or a web form), acknowledgement, triage into compliance vs. security inquiries, assignment and response, and record keeping. The external inquiry channel designated in chapter 02 is the entry point, and the deliverable is generated as inquiry-response.md. If an intake turns out to be an actively exploited vulnerability, note that the EU CRA reporting clock in 3-3 (if it applies to you) starts at that same moment.

Triage criteria for low-quality AI-generated reports:

Once you open an intake channel, reports that are not real vulnerabilities arrive alongside the real ones. That share has grown enough recently that running the channel has become a cost of its own.

curl ended the monetary rewards of its seven-year bug bounty on 2026-01-31 after its confirmed vulnerability rate fell from above 15% to below 5% during 2025. It still accepts reports through GitHub private vulnerability reporting and a security email address (The end of the curl bug-bounty)
HackerOne reported that total submissions across its platform grew roughly 76% over the twelve months ending March 2026 while signal rates stayed about the same. What grew was triage load, not work that needed fixing
Elastic received over 1,390 reports in the first half of 2026 alone, exceeding the full-year totals for 2024 and 2025 combined, and measured the cost of triaging a single report at roughly $2
JFrog reported on 2026-07-30 that of 55 SQLite advisories published by one GitHub account, 54 were entirely fabricated. Several of them had been listed in NVD with a CVSS 9.8 Critical score

Adding these three checks, in order, to the triage step of inquiry-response.md closes out most low-quality reports early.

Does the code exist: confirm that the file, function, and version the report names actually exist. Close a report that points at a code path that is not there.
Is it reproducible: confirm there are runnable reproduction steps or proof-of-concept code. If not, request them with a reply deadline (14 days, for example) and close on no response.
What is the impact: confirm that your distribution actually uses that code path. If it does not, record not_affected in VEX and close.

Do not accept the CVSS score the reporter proposes; recalculate it yourself. The public CVE submission form has no real identity verification, so anyone can submit a vulnerability description and propose a CVSS score. That is how the fabricated advisories in the JFrog case came to be listed as Critical.

Published examples — intake channel and notices

A procedure that exists only on paper cannot be verified. The open source project TRUSCA publishes both of these in its repository.

SECURITY.md — the vulnerability intake channel. It puts GitHub private vulnerability reporting first, offers encrypted email as a fallback, and states plainly that unpatched issues must not be filed as public issues. This is what the "publicly visible method of inquiry" required by ISO/IEC 5230 §3.2.1 and ISO/IEC 18974 §4.2.1 looks like in practice
NOTICE and THIRD_PARTY_NOTICES.md — the notices shipped with the distribution, matching the compliance artifacts in 5230 §3.4.1

Borrow the structure, not the contents. The PGP fingerprint in that SECURITY.md is still a placeholder; contact details and keys only mean something once they hold real values.

CI/CD integration points

To be sustainable, the process must be integrated naturally into the development flow. Automating manual checks reduces the burden on the program manager and lowers the risk of omissions.

YAML
# .github/workflows/oss-compliance.yml
name: OSS Compliance Check

on:
  pull_request:
  schedule:
    - cron: '0 9 * * 1' # Every Monday at 09:00 UTC (18:00 KST)

jobs:
  license-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - name: Generate SBOM
        run: |
          docker run --rm -v "$(pwd)":/project \
            anchore/syft:latest /project \
            --output cyclonedx-json > sbom.cdx.json
      - name: License check
        run: echo "License review step"

The main CI/CD integration points are as follows:

PR stage: Automatically check the license when a new dependency is added.
Build stage: Generate the SBOM automatically.
Before release: Run the release checklist automatically.
Periodic scan: Monitor for known CVEs (on a cron schedule).

Even in an environment without CI/CD, you can run the same process based on a manual checklist. When you introduce CI/CD later, you can automate the manual steps one at a time.

3. Self-study

Self-study mode (about 1 to 2 hours)

The process requires significant customization to fit your company's environment. You proceed by talking with the agent.

Preparation

Before running the agent, organizing your company's situation in advance for the 7 questions below will let the conversation move quickly.

The 7 questions the agent asks

The CI/CD tools you currently use (GitHub Actions / Jenkins / GitLab CI / None / Other)
Your software release cycle (Daily / Weekly / Monthly / Irregular)
Whether you use an issue tracker (GitHub Issues / Jira / None / Other)
The approval stage for open source use (Program manager alone / Team lead approval / Committee approval)
Do you plan to contribute to external open source projects? (Yes / No)
Do you plan to release your in-house software as open source? (Yes / No)
Do you have a channel in place to receive external license/vulnerability inquiries? (Channel address or "Not yet")

Step-by-step exercise

Once you have prepared answers to the 7 questions above, run the agent.

Step 1: Run the agent.

Check before running

First terminate the current Claude session (/exit or Ctrl+C), then run the command below in a new terminal.

Bash
cd agents/en/04-process-designer
claude

Agent conversation example (click to expand)

The agent asks the 7 questions in order. Below are sample answers for a startup.

#	Question	Sample answer
1	CI/CD tools in use	GitHub Actions
2	Release cycle	Weekly
3	Issue tracker	GitHub Issues
4	Usage approval stage	Team lead approval
5	Plans to contribute to external projects	No
6	Plans to release in-house software	No
7	External inquiry channel	opensource@example.com in operation

For the list of generated files, see the Expected output table below. Some items must be filled in manually.

Items you must fill in manually:

Confirm the GitHub Actions workflow file path
The approver's name and contact details

Step 2: When the Claude prompt opens, type start.

Step 3: Answer the 7 questions in order.

Step 4: Review the generated Mermaid flowchart.

The diagram inside output/process/process-diagram.md is a "drawing" written in text, so opening it in a plain editor shows code, not a picture. To see the actual rendered diagram, use one of these two options.

If this repository is hosted on GitHub: opening the file on GitHub renders it as a picture automatically.
If you're only working locally: open mermaid.live, copy the whole code block in output/process/process-diagram.md that starts with ```mermaid and ends with ```, and paste it (Cmd+V or Ctrl+V) into the input pane on the left — the diagram appears on the right immediately. In VS Code, an extension like "Markdown Preview Mermaid Support" also renders it in the Preview pane.

Review it to make sure it matches your actual workflow. If corrections are needed, ask the agent for changes or edit the file directly.

Step 5: Check the files created in the output/process/ directory.

Bash
ls output/process/

Step 6: Plan your CI/CD integration.

Make a plan to add workflow files matching your current CI/CD tools to your project. If immediate adoption is difficult, schedule it for the next sprint or the next release cycle.

When you get stuck

No CI/CD: Answer "None." The agent creates a process based on a manual checklist. After you introduce CI/CD, you can automate it step by step.
Ambiguous approval stage: Enter exactly what your team actually uses. You can change it later.
Mermaid won't render: Check it yourself at mermaid.live.

Expected output

File	Content
`output/process/usage-approval.md`	Open source adoption approval form and procedure
`output/process/distribution-checklist.md`	Pre-release compliance checklist
`output/process/vulnerability-response.md`	Vulnerability response procedure (includes the CVD (Coordinated Vulnerability Disclosure) procedure)
`output/process/inquiry-response.md`	Procedure for responding to external license/security inquiries
`output/process/process-diagram.md`	Complete process overview including a Mermaid flowchart
`output/process/contribution-process.md`	Contribution process (created when Q5 is "Yes")
`output/process/project-publication-process.md`	Project disclosure process (created when Q6 is "Yes")

Standard requirements met

Completing this exercise satisfies the requirements below.

5230 §3.1.5, §3.2.1, §3.3.2, §3.4.1, §3.5.1 · 18974 §4.1.5, §4.2.1

The original self-certification question and the verification material for each item are in the Requirements Detail Matrix.

4. Completion checklist

You must complete all of the items below to finish this chapter.

process-diagram.md example (excerpt)

Ensure that the generated flowchart contains a structure similar to the one below.

This step meets the ISO/IEC 5230 3.1.5, 3.2.1, 3.3.2, 3.4.1, and 3.5.1, and ISO/IEC 18974 4.1.5 and 4.2.1 requirements.

Example deliverables

See the actual format of the generated files in Process deliverables best practice.

5. Next steps

Once all output/process/ deliverables have been created, move on to the SBOM creation step.

Check before running

First terminate the current Claude session (/exit or Ctrl+C), then run the command below in a new terminal.

Bash
cd agents/en/05-sbom-guide
claude

Or, if you want to read the documentation first, go to Create SBOM: Building a software bill of materials with syft and cdxgen.

An SBOM (software bill of materials) is the key tool for confirming that the processes created in this chapter actually work. By recording which open source is included in a machine-readable format, you can automatically check license obligation compliance and the scope of impact of vulnerabilities.