Skip to content

Security: clsoftlab-lang/chefcell

Security

SECURITY.md

Security Policy

ChefCell (셰프셀) is unusually sensitive for an open project: it touches physical safety (hot oil, high-pressure water, electricity, moving robots), food safety (food that people eat), and payment-adjacent, partner-gated integrations (delivery-platform ordering and courier dispatch). We treat security and safety reports with matching care.

Please report privately

Do not open a public issue for a vulnerability or a safety-critical flaw. Public disclosure could put people, food safety, or an operator's live deployment at risk before a fix exists.

Instead, report privately:

  • Use GitHub's private vulnerability reporting on this repository (Security → Report a vulnerability), if enabled; or
  • Contact the maintainers at CLSOFTLAB via a request in a GitHub Discussion asking for a private channel (do not include details in the public post), and we will follow up.

Please give us reasonable time to investigate and fix before any public disclosure. We will acknowledge your report, keep you updated, and credit you if you wish.

What especially counts here

Report privately if you find any of these:

  • Safety-authority bypass — any path where software could command motion, heat, high-pressure water, or a door/serve-hatch open in a way that should be blocked by an interlock, occupancy check, cooldown, or the safety PLC. In a real build the hardware safety PLC and E-stop are the final authority; a software route around that is a serious report.
  • Water-meets-hot-oil / thermal / fire sequencing errors, or a missing cooldown-before-open/wash gate.
  • Food-safety logic that could allow expired stock, broken cold-chain, cross-contamination, or allergen mix-ups to pass unnoticed.
  • Secrets exposure — a delivery-platform key, token, or credential committed to the repo or leaked by the software. (Keys must be env-only.)
  • Delivery/courier or payment-adjacent flaws — e.g. an adapter that could place, alter, or accept real orders without an approved partner agreement, or mishandle customer/order data.
  • Tampering with the HACCP / inspection log — anything that lets hygiene evidence be forged or silently altered.
  • Conventional software vulnerabilities in the API/orchestrator (injection, auth bypass, SSRF via a webhook, etc.).

Scope and honest limits

This repository is a reference design + software (mock/simulator). It is not a certified or food-safe system. A real deployment's security and safety also depend on the operator's certified safety PLC, licensed fabrication, hosting, and signed delivery-partner agreements — those are outside this repo. Nothing here is legal, food-safety, or engineering advice.

Handling secrets

  • API keys/secrets are supplied by the operator through environment variables and are never committed. .env is git-ignored.
  • If you accidentally commit a secret, treat it as compromised: rotate it immediately with the issuing platform and tell the maintainers so history can be handled.

There aren't any published security advisories