Argus

Concepts

Cleanup: how Argus removes its own work

Adding a fix is only half the job. Argus signs every change it makes, and on later runs it takes those changes back out once they have stopped protecting anything, so your project keeps only what it actually needs.

Why Argus removes things

Every edit Argus makes carries a small comment identifying it:

a fix Argus added
<!-- PATCH|OVERRIDE|RM-b2c3d4e5f6a7|spring-kafka -> 3.2.4 (managed). -->
<dependency>
    <groupId>org.springframework.kafka</groupId>
    <artifactId>spring-kafka</artifactId>
    <version>3.2.4</version>
</dependency>
what the comment means
Argus added this line, to fix a specific security advisory,
by holding spring-kafka at 3.2.4.

The comment is how Argus recognises its own work later.
Without it, Argus would treat the line as yours and never touch it.

Those fixes do not stay useful forever. A few months later the platform you build on (Spring Boot, or your own company parent POM) ships a version that is already safe. At that point the line Argus added is doing nothing except sitting in your file, and quietly holding that dependency wherever Argus left it.

Left alone, this accumulates. A project that has been running Argus for a year collects a layer of pins that nobody can safely remove by hand, because nobody remembers which are still load-bearing. Cleanup is what stops that happening.

The question Argus asks

There is one question, and it is deliberately narrow:

If I take this line out, does the security problem come back?

To answer it, Argus removes the line, rebuilds your dependency tree with Maven exactly as your build would, and re-checks the result against the advisory databases. If nothing is vulnerable without the line, the line goes.

Two kinds of change

What “removing” means depends on what Argus did in the first place, and the difference matters when you read the diff.

Lines Argus added

Most fixes add something that was not in your file before: a pinned version, an exclusion, an imported bill of materials. Before Argus, that line simply was not there, so removing it returns your file to its original shape and makes it shorter.

pom.xml (before cleanup)
<dependencyManagement>
    <dependencies>
        <!-- PATCH|OVERRIDE|RM-b2c3d4e5f6a7|spring-kafka -> 3.2.4 (managed). -->
        <dependency>
            <groupId>org.springframework.kafka</groupId>
            <artifactId>spring-kafka</artifactId>
            <version>3.2.4</version>
        </dependency>
    </dependencies>
</dependencyManagement>
pom.xml (after cleanup)
<!-- The whole block is gone. Spring Boot now supplies a
     safe version of spring-kafka on its own, so nothing is
     lost by letting it. -->

Values Argus changed

Some fixes do not add a line at all: they change a number you already had. Upgrading your parent POM is the common case. There is nothing for Argus to remove there: the line is yours, and putting the number back would be undoing an upgrade on purpose.

What can go out of date is the comment, because it names a version. If your team (or Dependabot) later moves that version on, the comment starts contradicting the file:

the comment no longer matches
<!-- PATCH|BUMP|...|spring-boot-starter-parent -> 4.0.7. -->
<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>4.1.0</version>
</parent>
after cleanup: comment removed, version untouched
<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>4.1.0</version>
</parent>

The comment claimed 4.0.7 while the file said 4.1.0. Argus removes the sentence that had become untrue and leaves your version exactly where you put it.

When a version goes down

This is the one change most worth understanding, because it can look alarming in a diff.

Suppose Argus pinned spring-kafka to 3.2.4 to fix an advisory. Later you upgrade Spring Boot, and the new Boot manages spring-kafka at 3.2.1: a lower number, but one the advisory no longer affects. The pin is now pointless. When Argus removes it, your resolved version moves from 3.2.4 down to 3.2.1.

That is the intended result. Your project goes back to using whatever your platform provides, which is where it would have been if Argus had never been involved. Nothing becomes vulnerable: Argus checked before removing.

What Argus will never do

  • Leave you worse off. If removing a fix would expose a problem that has no available patch, Argus abandons the cleanup for that run and says so. Any unrelated fix in the same merge request still goes ahead.
  • Touch a line you wrote. No Argus comment, no changes. Ever.
  • Delete a dependency. Where Argus only changed a version number, cleanup removes the comment and nothing else.
  • Remove something silently. Every removal appears in the merge request and the PDF report, with the reason.

Seeing it in your merge request

When a cleanup travels alongside a security fix, it appears under Also removed:

merge request body
### Also removed

- `org.springframework.kafka:spring-kafka`: No longer needed — the project
  resolves a safe version without it, so the pin has been removed.
PDF report: “Overrides released”
RELEASED                              SCOPE           EVIDENCE
org.springframework.kafka:            edit removed    No longer needed — the project
spring-kafka                                          resolves a safe version without it.

spring-boot-starter-parent            comment only    Comment out of date — it still
                                                      refers to 4.0.7, but the parent
                                                      is now on 4.1.0.

The scope column is the one to read first. Edit removed means a line came out and what your build resolves may change. Comment only means nothing but a stale comment was deleted.

A related section, Resolved without a pin (added in 3.3.2), covers a different situation: Argus planned a pin for a vulnerable transitive, and the same run’s other upgrades (a coupling companion, an anchor) settled that coordinate safe before publication, so the pin was withdrawn and never shipped. Everything under Also removed corresponds to a deletion you can see in the diff; entries under Resolved without a pin deliberately do not, because the pin only ever existed inside Argus’s candidate patch.

When there is nothing left to fix, Argus opens a maintenance-only merge request containing just the removals.

Taking a fix over yourself

If you decide a fix should be yours to manage, delete the <!-- PATCH|… --> comment and keep the change. Argus will treat the line as your own from then on and will never revisit it. Keep the comment with its change if you want Argus to carry on managing it: moving one without the other is the one thing that confuses it.

For the full decision, including its known limits, see the strategy ladder.