Read the risk before the record.

These guides organize the reviewed layer of Observatory by security question. They explain what the model means, what the calling code still needs to prove, and which exact API records carry the evidence.

Command execution

Keep untrusted values out of shell grammar and process selection.

CWE-787 reviewed records

The question to answer

Can any value change the executable, argument boundaries, or shell syntax?

What to verify

  1. Prefer a fixed executable with an argument array.
  2. Keep shell mode disabled unless shell syntax is the explicit requirement.
  3. Constrain executable selection and validate each argument for its domain.

SQL queries

Keep query structure fixed and bind changing values as data.

CWE-895 reviewed records

The question to answer

Does caller-controlled text become part of the statement grammar?

What to verify

  1. Use the driver’s parameterized or prepared-statement interface.
  2. Do not build identifiers or clauses from unchecked input.
  3. Review raw-query escape hatches separately from ordinary query APIs.

Deserialization

Treat formats that can construct objects or invoke code as executable boundaries.

CWE-5026 reviewed records

The question to answer

Can this loader construct more than plain data from the supplied bytes?

What to verify

  1. Prefer a data-only format at trust boundaries.
  2. Select a safe loader or restricted schema explicitly.
  3. Bound document size and complexity before parsing.

Dynamic evaluation

Keep source code and user-controlled data in different channels.

CWE-94 · CWE-954 reviewed records

The question to answer

Can input cross from data into the host language’s executable grammar?

What to verify

  1. Replace evaluation with a parser for the intended data shape.
  2. Expose an allow-listed operation set for dynamic behavior.
  3. Bound size and nesting even when the accepted grammar is limited.

Memory bounds

Carry destination capacity with every copy, write, and formatted output.

CWE-120 · CWE-7874 reviewed records

The question to answer

Is the write length proven to fit the destination, including termination?

What to verify

  1. Check the destination capacity before the operation.
  2. Use length-aware APIs and handle truncation as an error.
  3. Keep termination and integer-overflow behavior explicit.

Model vocabulary

Source
Introduces data into the analysis.
Sink
Consumes data at a security-sensitive boundary.
Sanitizer
Constrains data under stated conditions; it is not universal proof of safety.
Summary
Carries or transforms data between access paths.
Access path
Names the argument, return value, property, or binding the model tracks.
Model fact
An Atropos classification used as analysis evidence, not an application-specific verdict.

How to use a record

  1. Locate the boundary.Read role, kind, and access path before drawing a conclusion.
  2. Check the authority label.Reviewed guidance and raw model facts make different promises.
  3. Open the evidence.Follow the immutable source link and verify the model ID upstream.
  4. Validate the call site.Confirm versions, argument constraints, and the actual data flow in your code.

Scope boundary

A missing record is not proof that an operation is safe. Atropos describes known API semantics; it does not execute your application or replace code review.

Read the coverage statement