Keep decisions in cra.yml

cra.yml is a versioned YAML record in your product root. Commit it with the product. Init combines detected facts with your answers. Later commands read this file without repeating the interview. Init refuses to replace an existing profile. Invalid fields or values stop the command with an error.

Partial answers and unknowns#

An answers file uses the same schema, starting with version: 1. Omitted fields remain for detection or the interview. With --no-prompt, unanswered decisions stay unknown. Use a temporary file outside your product repository, then remove it. See the tested partial answers example.

fendkit init --no-prompt --answers /tmp/maker-answers.yml --release ../dist/plugin.zip

The file must contain your own answers, not the example maker's details. classification.categories: null means unknown; [] deliberately records that none of the Annex III/IV categories apply. Never substitute [] for an unknown decision. Init derives the highest class from explicitly selected categories. Keep an unknown classification.answer as unknown with null categories. If you decide that no listed category applies, init saves default with []. If you supply both an answer and categories, they must agree. unknown or null answers need null or omitted categories, rather than a list. A conflict stops the command and names the field to fix. If you supply only categories, init records the highest selected class. Saving partial answers before init keeps the answer omitted. Existing profiles with only an answer need no added categories.

Init preserves supplied decision dates, explicit null dates and reviewer names. Only an omitted date for a decided answer is filled with today’s date. Unknown or unanswered decisions remain undated. Later scan/docs/check preserve unknown decisions without repeating the interview.

Supported fields#

Text may be null when unknown. Dates use YYYY-MM-DD. Booleans use true, false or null. Lists are YAML sequences, not comma-separated strings.

Section	Fields and accepted values
version	Required integer 1.
product	name, type, version, description, release, distribution (list of text). Types: wordpress-plugin, wordpress-theme, composer-package, npm-package, application, other.
manufacturer	name, address, website.
role	answer: manufacturer, open-source-steward, not-in-scope, unknown; answers mapping below; decided_by, decided_on.
role.answers	sold, paid_edition, paid_support, donations_only, hosted_only, all nullable booleans.
classification	answer: default, important-class-i, important-class-ii, critical, unknown; categories: list of IDs from init's Annex III/IV list or null; decided_by, decided_on, note.
security_contact	email, url, policy_url. Use real contact details; drafts require valid addresses/HTTPS links where appropriate.
support	end (date), versions (text version line), updates (text method).
components	List of manual component mappings described below.
triage	List of exact advisory/component-version decisions described below.

Release paths and patterns resolve relative to the project root, including sibling paths. --release overrides the saved path for that scan. Update the profile's path when you want later scans to use a different release. Unknown product versions need a real version before evidence can be current. See inventory. Windows releases on another drive are kept as absolute paths that work only on that machine and may expose personal directory names when reports are shared.

Manual components#

Each component supports name, version, ecosystem, purl, path, shipped and note. Use npm or composer for supported vulnerability lookups. Omit shipped to keep detected behavior; true and false are explicit decisions, and shipped: null explicitly makes that occurrence unknown. Init and triage preserve these values and your comments. When the same component appears more than once, one shipped copy makes the group shipped. Otherwise, one unknown copy makes the group unknown. Known versions and purls must come from evidence.

To add an unrecognized library, omit path. That field only matches an already detected occurrence. Record the file location and shipping evidence in note. This example leaves the version unknown until you verify it:

components:
  - name: widget
    version: null
    ecosystem: npm
    purl: pkg:npm/widget
    shipped: true
    note: "assets/js/widget.min.js is present in the shipped ZIP; version not yet verified"

To correct an already detected occurrence, use its exact path from cra/reports/inventory.json. For example, after verifying the shipped banner:

components:
  - name: moment
    version: 2.24.0
    ecosystem: npm
    purl: pkg:npm/[email protected]
    path: assets/js/vendor/moment.min.js
    shipped: true
    note: Version verified from the shipped banner

Manual entries can add or correct detected evidence; they do not make unsupported formats covered or prove the absence of other bundles.

Saved triage#

Prefer the triage command. Each record has advisory, component (exact purl including version), status, justification, reason, decided_on. Status is affected, not_affected, fixed or under_investigation. All need a reason and decision date; not_affected also needs a supported OpenVEX justification. See the generated reference for its values.

Profile updates by triage preserve YAML comments. Scan and docs do not save new answers. Existing maker documents also remain untouched; review changed facts yourself using the documents guide.