Self-service means a developer can start a service, add an approved dependency, run a scan and request an exception without filing a ticket and waiting. The security team defines the rules once, and the platform applies them on demand.
What the CNCF paper says
The CNCF platforms white paper lists attributes of successful platforms. Several map cleanly onto dependency security:
| Attribute from the paper | In dependency security terms |
|---|---|
| Platform as a product | Treat the scan, registry and template as products with users and a roadmap |
| User experience | Offer results in the IDE, CLI, pull request and portal, where people already work |
| Documentation and onboarding | Ship the template with docs, a golden path bundle |
| Self-service | Request and receive capabilities autonomously and automatically |
| Reduced cognitive load | Hide registry and scanner complexity, show what to do next |
| Optional and composable | Let teams use parts and bring their own tools where needed |
| Secure by default | Controls on from the first commit, with compliance validation against your rules |
The paper's own self-service example is requesting a database by running a command or filling out a form. The security equivalent is getting a new package approved through a form or a command, with an answer in minutes.
Where tickets creep back in
| Request | Ticket based flow | Self-service flow |
|---|---|---|
| Add a new package | Email security, wait days | Policy auto-approves known good, queues the rest |
| Run a scan | Ask for a scheduled job | Scan runs on every pull request |
| Get an exception | Open a ticket, wait | Form with owner, reason and expiry, auto-routed |
| See my findings | Request a report | Portal view or CLI command |
| Create a service | Ask platform team | Template with a create button |
Every row you move to the right frees security staff for work that needs judgment.
Self-service is not self-approval
Autonomy has limits. Self-service works because rules are encoded: what is auto-approved, what needs a person, and what is blocked. The paper's attribute on being optional and composable also helps: teams can run their own tools, but only the path carries the default guardrails and the evidence trail.
Steps to move toward it
- List the five most common dependency requests to the security team.
- For each, write the rule a person applies today.
- Encode the rule as a policy check, with a human queue for the cases it cannot decide.
- Expose the result where developers work.
- Measure time to answer, before and after.
- Review the auto-approved set quarterly for mistakes.
For ownership questions on this path, see who owns dependency intake.
Where Safeguard fits
Safeguard provides policies, gates and guardrails you can encode as rules, SBOM and dependency scanning in the CLI, IDE extensions and pull requests, and compliance and evidence automation. Try a free scan at gold.safeguard.sh/scan.
Try it yourself
Open the demo and look at how a finding moves from detected to resolved, then ask which of those steps need a person at all.
Click through it at your own pace, or open it full screen.
Quick check
Does self-service remove the security team?
No. It moves routine decisions into encoded rules so the team spends time on the cases that need judgment.
What is the first thing to make self-service?
Pick the most common request, often adding a new package, and write down the rule a person applies today.
Sources
Last reviewed: 19 October 2026.
