# Software, APIs and supply chain

Manage object authorization, dependencies and release provenance in one product trail.

SecNet.Work | 2026.10 | 2026-10-21

Authentication does not establish authorization for every API object. Product security also covers dependencies, build environments and delivered components. OWASP API Security Top 10:2023 is an awareness resource, not a complete test scope. EU CRA applicability depends on product and role; parts of reporting apply from 11 September 2026, with general application from 11 December 2027.

## Work boundary
Authorized test environments and synthetic accounts only. This pack is not a conformity assessment or an attack target.

## Process

### 1. Map data and objects
Map endpoints to users, tenants, objects and actions. Define allowed and rejected cases for each action. Test server-side object authorization rather than role names.

Expected evidence: Authorization matrix and negative test

### 2. Trace dependencies
Record direct and transitive components with version and source. State SBOM scope, release and refresh process. An outdated ownerless SBOM is not a current product inventory.

Expected evidence: Release-bound component inventory

### 3. Connect build and delivery
Link code approval, build identity, dependency source and delivered artifact digest. Separate production keys from test jobs. Distinguish signature presence from evidence of signature verification.

Expected evidence: Build trail and verified digest

### 4. Verify remediation and acceptance
Bind findings to release, owner and retest. Repeat authorization tests across two tenants. Assess support period, reporting and product scope with legal/product teams.

Expected evidence: Release-specific retest

## One control, three perspectives

### Operator
Does the server reject the wrong object?
Use two synthetic tenants for a negative test.
Evidence: Request, expected and actual result

### Auditor
Which release was delivered?
Match build records with artifact digest.
Evidence: Release and provenance trail

### Leader
Which product risk remains?
Own open findings and support decisions.
Evidence: Product risk record

## Evaluate evidence

**Claim:** Tenant data separation works.

**Weak support:** The login page asks for a password.

**Stronger support:** Cross-tenant object read/write attempts were rejected server-side; release and results are recorded.

**Rationale:** Authentication does not explain authorization to another tenant’s object.

## Decision desk
A test account sees its own project; cross-tenant tests are missing.
Start: start

### start
First step?

- **Add an authorization matrix and two-tenant negative tests** (good)
  You measure isolation as well as normal use. Check whether rejection covers all operations.
  Next: verify

- **Declare the API secure because login works** (risk)
  Login does not test object access. Verify tenant separation server-side and per action.
  Next: repair

- **Close without a rationale** (incomplete)
  Deferring an open issue is not closure evidence. Record the uncertainty, owner and next verification step.
  Next: revise

### verify
Reads are rejected, but the export endpoint returns data.

- **Apply the same authorization policy to exports and test** (good)
  Alternative operations can cross the boundary. Retest the correction using the same tenant cases.
  Next: planned

- **Accept the claim without testing** (risk)
  The initial claim and observed result differ. Support closure with a repeatable check in the same scope, rather than a promise or ticket status.
  Next: revise

### repair
A faulty release was published.

- **Constrain the release, assess impact and open a correction trail** (good)
  The product owner coordinates impact and rollback. Link records to the delivered release.
  Next: planned

- **Delete the earlier record and close** (risk)
  Deleting the earlier decision undermines learning and accountability. Link the new action to the prior record and keep the rationale and residual risk visible.
  Next: revise

### supported
This decision is supported by the evidence in the example. Verify closure conditions in your own scope.

### revise
The decision lacks support. Record the rationale and required evidence, then reassess.

### planned
A remediation path is defined. Keep the matter open until implementation and verification are complete.

## Worked example
Entirely fictional.
- Release: demo-1.2
- Object / action: Report export
- Tenant: A → B
- Expected: Reject
- Observed: Test pending
- Ticket / test: Fictional APP-018

## Closure checklist
- [ ] Negative authorization tests exist.
- [ ] SBOM bound to release.
- [ ] Delivered artifact provenance verified.
- [ ] Correction tested in the same scope.

## Official sources
- [OWASP API Security Top 10 — 2023](https://api-security.owasp.org/editions/2023/en/0x03-introduction/)
- [NIST SP 800-161 Rev. 1, November 2024 update](https://csrc.nist.gov/pubs/sp/800/161/r1/upd1/final)
- [European Commission — Cyber Resilience Act](https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act)

https://secnet.work/learn/toolkits/software-supply-chain