feat(ci): add PyPI build + NuGet pack jobs, complete package coverage

[imran-siddique]

Summary

Adds PyPI and NuGet build validation to CI so packaging issues are caught on PRs:

• build-pypi (matrix): \python -m build\ for all 7 PyPI packages
• test-dotnet: added \dotnet pack\ step to verify NuGet packaging
• Added \�gent-runtime\ and \�gent-lightning\ to path filters, lint, test, and safety matrices
• All wired into ci-complete gate

Full CI coverage now matches ESRP pipeline:

Ecosystem	Packages	CI Job
PyPI	7 packages	build-pypi, lint, test
npm	5 packages	build-npm
NuGet	1 package	test-dotnet (build+test+pack)
Rust	1 crate	build-rust
Go	1 module	build-go

[github-actions]

🤖 AI Agent: code-reviewer

Review Summary

This pull request introduces PyPI and NuGet build validation to the CI pipeline, ensuring that packaging issues are caught during pull requests. It also expands the CI coverage to include the agent-runtime and agent-lightning packages, aligning the CI pipeline with the ESRP pipeline. While this is a valuable improvement to the CI/CD process, there are a few areas that require attention to ensure correctness, security, and maintainability.

---

🔴 CRITICAL

1. Missing Security Validation for PyPI Packages:

   • The build-pypi job builds Python packages but does not include any security validation for the generated artifacts (e.g., scanning for malicious code or verifying dependencies).
   • Action: Add a step to scan the generated .whl files for vulnerabilities or malicious code using tools like twine check or bandit. This ensures that the packages are safe before publishing.

2. NuGet Package Verification:

   • The test-dotnet job verifies the existence of the .nupkg file but does not validate its integrity or contents.
   • Action: Add a step to validate the NuGet package using nuget verify or a similar tool to ensure the package is correctly built and free of tampering.

---

🟡 WARNING

1. Potential Breaking Changes in Python Version Matrix:

   • The test job now includes Python 3.13 in the matrix, which is currently not officially released or stable.
   • Action: Consider removing Python 3.13 from the matrix until it is officially supported. Including it prematurely may cause unnecessary failures or compatibility issues.

2. Backward Compatibility for New Packages:

   • Adding agent-runtime and agent-lightning to the CI pipeline assumes that these packages are ready for production. If they are not backward-compatible with existing systems, this could lead to issues.
   • Action: Ensure that these new packages are thoroughly tested for backward compatibility before merging this PR.

---

💡 SUGGESTION

1. Improve Artifact Management:

   • The build-pypi and test-dotnet jobs generate artifacts (.whl and .nupkg files) but do not upload them to the CI pipeline for further analysis or debugging.
   • Action: Use actions/upload-artifact to store the generated artifacts, making them available for inspection or reuse in subsequent jobs.

2. Add Dependency Locking for Build Tools:

   • The build-pypi job installs build and setuptools without locking their versions, which may lead to non-deterministic builds.
   • Action: Use a requirements.txt file or pin the versions of these tools to ensure consistent builds.

3. Expand Test Coverage for New Packages:

   • While agent-runtime and agent-lightning are added to the CI pipeline, there is no mention of additional test cases specific to these packages.
   • Action: Ensure that these packages have sufficient test coverage, especially for edge cases and security-related scenarios.

4. Add Documentation for New CI Jobs:

   • The new build-pypi and test-dotnet jobs are not documented in the repository. This could make it harder for contributors to understand the CI pipeline.
   • Action: Update the repository's CI documentation to include details about these new jobs and their purpose.

5. Consider Parallelizing CI Jobs:

   • The CI pipeline now includes additional jobs, which may increase the overall runtime.
   • Action: Review the pipeline's execution time and consider parallelizing jobs where possible to reduce the total runtime.

---

Final Assessment

This PR introduces valuable improvements to the CI/CD pipeline, particularly in catching packaging issues early. However, there are critical gaps in security validation and artifact verification that need to be addressed before merging. Additionally, attention should be given to backward compatibility, test coverage, and documentation to ensure a smooth integration.

• Merge Recommendation: Conditional approval, pending resolution of critical issues and consideration of warnings.

[github-actions]

🤖 AI Agent: security-scanner — Security Review of PR: `feat(ci): add PyPI build + NuGet pack jobs, complete package coverage`

Security Review of PR: feat(ci): add PyPI build + NuGet pack jobs, complete package coverage

This PR introduces CI jobs for building and validating PyPI and NuGet packages. While the changes are primarily related to CI/CD workflows, they touch critical areas of the repository that could impact the security of the microsoft/agent-governance-toolkit. Below is a detailed security analysis based on the provided diff.

---

Findings:

1. Credential Exposure in Logs

Severity: 🔴 CRITICAL
Issue: The ls -la dist/*.whl and ls -la ./nupkg/*.nupkg steps in the build-pypi and test-dotnet jobs respectively could inadvertently expose sensitive information if the filenames or paths contain secrets (e.g., credentials embedded in filenames). This is especially risky if the CI logs are publicly accessible or shared.
Attack Vector: An attacker could monitor CI logs to extract sensitive information from filenames or paths, potentially compromising the security of the system.
Recommendation: Avoid printing filenames or paths directly to logs. Instead, use a secure method to verify the presence of files without exposing their names. For example:

- name: Verify wheel
  working-directory: packages/${{ matrix.package }}
  run: |
    if [ -z "$(ls dist/*.whl 2>/dev/null)" ]; then
      echo "No wheel file found!" && exit 1
    else
      echo "Wheel file exists."
    fi

---

2. Supply Chain Vulnerability: Hardcoded Dependency Versions

Severity: 🟠 HIGH
Issue: The pip install --no-cache-dir build==1.2.1 setuptools step in the build-pypi job hardcodes specific versions of dependencies. This could lead to supply chain attacks if the specified version contains vulnerabilities or is compromised.
Attack Vector: If an attacker compromises the build or setuptools package at the specified version, they could inject malicious code into the CI pipeline, potentially compromising the build artifacts.
Recommendation: Use a dependency lock file or a trusted source (e.g., a private PyPI mirror) to ensure the integrity of dependencies. Additionally, consider using pip install --require-hashes to verify the integrity of the downloaded packages.

---

3. Potential for Dependency Confusion

Severity: 🟠 HIGH
Issue: The pip install commands in the security job and the build-pypi job do not specify a trusted index URL (--index-url) or restrict package sources. This opens the pipeline to dependency confusion attacks, where an attacker could upload a malicious package with the same name as an internal package to a public repository like PyPI.
Attack Vector: An attacker could upload a malicious package to PyPI with the same name as an internal package (e.g., agent-runtime or agent-lightning). If the CI pipeline inadvertently pulls the malicious package, the build artifacts could be compromised.
Recommendation: Always specify a trusted index URL and disable the use of the public PyPI repository unless explicitly required. For example:

- name: Install build tools
  run: pip install --no-cache-dir --index-url https://your-private-pypi-mirror/ build setuptools

---

4. Lack of Integrity Verification for Build Artifacts

Severity: 🟡 MEDIUM
Issue: The CI pipeline builds PyPI and NuGet packages but does not verify the integrity of the generated artifacts. This could allow tampering during the build process to go undetected.
Attack Vector: If an attacker gains access to the CI environment, they could modify the build artifacts before they are published, injecting malicious code into the packages.
Recommendation: Implement artifact integrity checks, such as generating and verifying checksums (e.g., SHA-256) for the built packages. Store the checksums in a secure location for verification during deployment.

---

5. Potential for Insecure Python Dependency Installation

Severity: 🟡 MEDIUM
Issue: The pip install commands in the security job use the --no-cache-dir flag but do not include the --require-hashes flag. This could allow the installation of tampered packages if the PyPI index is compromised.
Attack Vector: An attacker could compromise the PyPI index and replace legitimate packages with malicious ones. Without hash verification, the CI pipeline would install the malicious packages.
Recommendation: Use pip install --require-hashes to ensure that only verified packages are installed. This requires maintaining a requirements.txt file with hashes for all dependencies.

---

6. No Verification of NuGet Package Integrity

Severity: 🟡 MEDIUM
Issue: The dotnet pack step in the test-dotnet job does not include any verification of the generated NuGet package. This could allow tampering during the build process to go undetected.
Attack Vector: An attacker could modify the NuGet package during the build process, injecting malicious code.
Recommendation: Implement a checksum verification step for the generated NuGet package. For example, use a tool like sha256sum to generate and verify checksums.

---

7. Lack of Isolation in CI Jobs

Severity: 🔵 LOW
Issue: The CI jobs run on ubuntu-latest, which is a shared environment. While this is common practice, it increases the risk of cross-job contamination or exploitation of vulnerabilities in the shared environment.
Attack Vector: An attacker could exploit a vulnerability in the shared environment to compromise the CI pipeline.
Recommendation: Consider using self-hosted runners with stricter isolation for critical jobs, such as those building and packaging artifacts.

---

Summary of Findings:

Finding	Severity
Credential Exposure in Logs	🔴 CRITICAL
Supply Chain Vulnerability: Hardcoded Dependency Versions	🟠 HIGH
Potential for Dependency Confusion	🟠 HIGH
Lack of Integrity Verification for Build Artifacts	🟡 MEDIUM
Potential for Insecure Python Dependency Installation	🟡 MEDIUM
No Verification of NuGet Package Integrity	🟡 MEDIUM
Lack of Isolation in CI Jobs	🔵 LOW

---

Recommended Actions:

1. Prevent Credential Exposure: Avoid printing sensitive information (e.g., filenames) directly to logs.
2. Secure Dependencies: Use a trusted index URL and dependency lock files to mitigate supply chain risks.
3. Verify Artifact Integrity: Add checksum generation and verification steps for all build artifacts.
4. Enhance Dependency Installation Security: Use --require-hashes with pip install to verify package integrity.
5. Consider Self-Hosted Runners: For critical jobs, use isolated environments to reduce the risk of cross-job contamination.

By addressing these issues, the CI/CD pipeline will be more resilient to potential security threats, ensuring the integrity and safety of the microsoft/agent-governance-toolkit and its downstream consumers.