Skip to content
Dekglas
Logmarq documentation contents
Logmarq documentation

Customer-response packages

Answer a customer's security or audit request with a reviewed bundle, and show later exactly what you sent.

Customer-response packages

A response package is a reviewed bundle for one customer: the notes, artifacts, bills of materials, and vulnerability decisions for the release they run. It lets you answer a customer's security or audit request with exactly what you reviewed, and show later what you sent.

Why you would use it

A customer's security team asks for the bill of materials and your vulnerability position for the version they run, ahead of their renewal review. Today that means gathering files from three tools, checking nothing internal slipped in, emailing a zip, and hoping someone remembers what was in it when the customer comes back six months later with a follow-up question.

A response package does that gathering from the release record, shows you the bundle before you freeze it, and keeps the frozen bundle with its checksum and a record of whom it went to. When the follow-up comes, you can see exactly what that customer received, and whether anything in it has since changed.

When you don't need it

If no customer ever asks for evidence about the version they run, you don't need packages: copy the notes or export a bill of materials when someone asks.

How it works in Logmarq

  • Selected from the record. A package version names, for each release it covers, the customer notes at an explicit version, artifacts, bills of materials as stored or as SPDX, and your decisions. A package for a customer can include that customer's own recorded deployments.
  • Never internal. A bundle never carries internal notes, pull request, issue, or commit references, anyone's name or email on your side, a supplier's VEX statement, a finding nobody decided, or another customer's deployments.
  • Previewed, then frozen on review. The preview lists every file with its checksum, what a reviewer should know (a release not yet released, findings nobody decided, notes that are not the latest), and what keeps it from review. Reviewing freezes the bundle and its manifest; every later export is exactly those bytes.
  • Delivery is a fact you record. Record how and to whom you sent it, and whether they acknowledged it. A reviewed version shows as stale when a newer source exists, with the reason.
  • Versions. A second version can start from the first's selection; an old version can be withdrawn with a reason, and stays on record.
ScreenshotA response package page showing a reviewed version with its files and checksums, the warnings the reviewer accepted, and a recorded delivery with its acknowledgement

What it will not claim

  • Logmarq never sends a package. It prepares, freezes, and records; you deliver it through your own channel.
  • Delivered is not accepted. A delivery is recorded as sent; an acknowledgement only when you record one.
  • Not yet used by an outside team. Response packages exist in the development build; no customer has received one yet.

Get started

Start a package from the project's page, choose the customer and the release they run, preview it, and review it. The CLI inside the image has the same steps, taking the selection as a JSON file:

docker exec logmarq logmarq package create <project> "Security review answer" --audience "Security team" --customer example-co
docker exec logmarq logmarq package draft <project> "Security review answer" --file selection.json
docker exec logmarq logmarq package preview <project> "Security review answer" 1
docker exec logmarq logmarq package review <project> "Security review answer" 1

Customers and the deployment map · Bills of materials · VEX: vulnerability decisions

Previous: Customers and the deployment map
Next: Glossary