A clear assessment boundary
Reviewers can see whether the record describes source analysis, a firmware image, a runtime observation or a manual decision.
Product security and AppSec
Keep the decision behind a security finding.
Product security and AppSec teams connect technical findings to release decisions. Magdox supports that work in two product workflows: source and application review in Code Security, and firmware and release evidence in FDIE. Each keeps the available evidence and assessment scope close to the review.
- Software
- Packages · versions · available relationshipsWhich components need review?
- Cryptography
- Algorithms · libraries · recognised usageWhere should a crypto migration begin?
- AI
- SDKs · model patterns · dependency evidenceWhich teams need to confirm AI usage?
Conceptual inventory map. Each inventory has its own command, output and coverage.
A practical scenario
A release owner asks whether an unresolved finding blocks shipment
The answer may depend on the affected code, component version, deployment assumptions and a previous investigation. The reviewer needs the evidence and the reasoning behind a disposition, plus a clear understanding of what changed since that decision was made.
- Bring to the review
- The relevant source scan or firmware assessment, the intended release, previous dispositions and product-specific context.
- Work towards
- A current applicability decision, an accountable remediation or acceptance record, and the evidence needed to revisit it.
The team's working process
Turn a scanner result into a product decision
Choose the appropriate evidence source
Use Code Security for supported source, dependencies and repository configuration. Use FDIE for the supplied firmware image, binary and component evidence. A company offering both does not itself establish source-to-binary provenance; retain the identifiers that connect your own build records.
Assess applicability and document the reason
Inspect the finding and coverage, confirm the affected product and involve its engineers. Record why the issue applies, why it does not or what risk is being accepted. Keep the required follow-up and review responsibility with the decision.
Revisit the decision when its assumptions change
A new release, different component, fresh advisory or changed scan scope can require another investigation. Use comparable source runs or FDIE release comparisons to identify the relevant change, then verify or revise the earlier disposition.
The result of the work
A useful handover between engineering and security.
A reasoned disposition
The decision explains its assumptions and evidence so another engineer can assess it later without recreating the entire investigation.
The right export
Use findings reports, recognised inventories and reviewed VEX where appropriate. Select an artifact that the intended recipient can interpret and retain.
A focused evaluation
Test the workflow with evidence your team already understands.
Choose a finding whose applicability is not obvious and walk through it with the engineering and release owners. Revisit it on a second source revision or related firmware release. Check whether the record makes changed assumptions and unresolved coverage visible.
Agree the participating team, input scope and expected deliverable before expanding the rollout. The most useful evaluation shows how a real owner investigates and acts on the result.
Practical questions
Planning for product security and appsec.
Do both products share one findings database?
No. Their applications and evidence stores remain separate. Your review process can use outputs from each without implying a combined dashboard.
Can a passed check approve the release?
The release owner makes that decision using the relevant engineering, operational and assessment evidence. Automated checks support the decision.
Can we procure both products?
Yes. An Enterprise order can identify both with explicit quantities, deployment scope and terms. Self-service subscriptions remain product-specific.
Choose the evidence source