What happens to a security decision after the code changes?

A security decision is made against a particular version of a system. Someone checks a path, understands a control, and decides what needs to happen.

Then the system changes.

The question we want to explore is simple: which earlier decisions now need another look?

The reasoning is worth keeping

Imagine a reviewer deciding that a scanner finding does not need a fix because every known caller passes through a validation boundary. The useful output is more than a closed ticket. It includes the path they checked, the validation behavior, the scope of the review, and the assumptions they could not verify.

Now imagine a new caller bypasses that boundary. The original decision may need to change even though the flagged line has not moved.

This is a hypothetical example. It describes the problem we want to investigate, not something ICTX detects today.

Keeping decision context is an established engineering practice. Architecture decision records preserve the context and reasoning behind choices so teams can understand them later. That supports the value of recording why a decision was made. It does not establish that automated security revalidation will work or that teams will adopt it. AWS guidance on architecture decision records.

Start with a decision people can inspect

We're starting with scanner triage. Today, ICTX investigates supported scanner findings and attaches code evidence to decisions. A reviewer can inspect the reasoning and see where more checking is needed.

That is a concrete place to start because it puts the evidence and the decision together. It also lets us learn which parts of that reasoning are useful to preserve. See the current workflow.

The next step is a question

We want to preserve that reasoning and check whether it still holds as software changes. A useful next step might record a decision's assumptions, identify a relevant change, and bring the affected decision back to a reviewer with an explanation.

We have not built that workflow. We still need to learn which changes matter, what context is available, and how to avoid creating another queue that people cannot keep up with.

The longer-term value we want to test is less repeated investigation and a clearer view of which decisions still deserve confidence. A team could reuse earlier work while keeping its limits visible. Those are intended benefits, not measured results.

AppSec is our entry point. Similar questions may apply to privacy requirements and architectural constraints, but those are possible directions for later discovery.

Help us test the first step

We're early and looking for strategic feedback. Would this first step help your team? What's missing?

Think of a recent decision you had to revisit. What changed? Where was the original reasoning? What did you have to investigate again? If another problem costs your team more, we want to understand that too.

Explore our vision or see the first step.