Security Policy

The Cinc Project takes security seriously. This page describes how to report a vulnerability in any Cinc binary, build pipeline, or supporting library we maintain.

Reporting a vulnerability

Please do not report security vulnerabilities through public GitLab issues, merge requests, or the Chef Community Slack.

Instead, email us at security@cinc.sh with:

• A clear description of the issue
• Steps to reproduce, or a proof-of-concept
• The Cinc product and version affected (e.g. Cinc Client 19.0.0, Cinc Server 15.10.91)
• The platform and any relevant configuration
• Your name and how you’d like to be credited (or “anonymous” if you prefer)

If the issue is sensitive, you can encrypt your report. Ask us for a current GPG key when you make initial contact, or include your own public key so we can reply encrypted.

What’s in scope

• All Cinc binaries we publish to downloads.cinc.sh and gems on rubygems.cinc.sh
• The build, packaging, and distribution pipelines under gitlab.com/cinc-project/distribution
• Our hosted services where applicable (omnitruck.cinc.sh, etc.)
• Cinc-specific patches we apply on top of upstream Chef sources

What’s not in scope

• Vulnerabilities in upstream Chef Software source code itself. Most Cinc binaries are built from unchanged upstream source. Please report those directly to Progress/Chef Software — we will of course pull in their fixes once available.
• The branding constants themselves (cosmetic, no security impact).
• The website itself (cinc.sh) for issues beyond data integrity — it’s a static site with no user data.

What you can expect from us

• An acknowledgement of your report within 5 business days.
• A more detailed response within 14 business days with our assessment and any clarifying questions.
• A confidential GitLab issue opened on the relevant Cinc project to track the work. If you have a gitlab.com account and let us know your handle, we’ll add you to the issue so you have visibility into our progress.
• For confirmed vulnerabilities: an estimated fix timeline, regular updates while we work on a fix, and credit in the release notes (unless you’d rather stay anonymous).
• A coordinated disclosure date that gives downstream users a reasonable window to upgrade.

We’re a small volunteer project, so timelines can vary depending on the severity and complexity of the issue. For critical vulnerabilities being actively exploited, please indicate that in your initial report so we can prioritize accordingly.

Disclosure policy

We follow coordinated disclosure:

1. Vulnerability is reported privately.
2. We open a confidential GitLab issue on the relevant Cinc project to track the work.
3. We confirm, scope, and develop a fix.
4. We agree on a disclosure date with the reporter (typically 60–90 days from report, sooner for critical issues).
5. Fixed Cinc release ships.
6. The confidential issue is flipped to public on GitLab, and a public advisory is posted on the Cinc blog with credit to the reporter. This gives downstream users and future researchers a permanent record of the issue and its resolution.

Security advisories

Past advisories are published on the blog and tagged Security. No security advisories have been published to date.

Receiving security announcements

The fastest way to stay informed about Cinc security updates is to subscribe to the blog RSS feed.