Hi @dotjem.com thanks for asking! The behavior that you describe for Firewall is accurate: when Firewall is enabled on a proxy repository, each new component being requested through the repository is evaluated against your organization’s risk policies only at the point of entry. If the component represents a known risk, your policy can indicate whether just to warn the developer, or flat out block the request. If blocked, the component is never stored in your proxy repository; and as long as the implicated risk is the same and the policy is still in force, subsequent requests for the same component will produce the same result. (Edit: the component is stored, and held in “quarantine.” You can choose to delete the component or release from quarantine to make it available.)
You’re right as well that risks can change over time. A proxied component that had no known risk at the point of entry might well be implicated by risk discovered later on. If that component is no longer used by your applications, it’s not an active risk, and will eventually be reaped by your Repository cleanup policies.
But if a new risk is associated with a component you rely on, the first question you’ll want to know is “in which applications are we using it?” It’s not easy to answer that question from just the view of the Artifact Repository. That’s where Lifecycle shines, allowing you to identify the applications you build, associate them with the git repositories containing the source, precisely inspect the true bills of materials for your projects, and continuously monitor the risks present in them. When fully adopted, Lifecycle will even open pull requests with the recommended remediation in the very apps that are using the dependency, either directly or transitively!
I hope that provides some clarity on the different use cases, let me know what you think!