Our organization is deploying a tool called Airflow on AWS.
The tool involves a list of restrictions, and our library firewall correctly blocks some of them. Currently, we authorize these libraries by issuing a waiver that specifies a timeframe and scope. Once that period expires, the waiver lapses and must be renewed. Since deployments happen periodically, this process—and the resulting blocks on the development team—becomes tedious for both parties.
Is there an alternative approach that would allow for this while maintaining traceability?
I hope I have explained the situation clearly; please let me know if you have any questions.
Thank you very much.
Best regards.
Hi, Jonathan,
I think I understand your situation clearly. Let me make two suggestions and then offer some advice.
First, in the latest version of IQ Server 205, Firewall can now send notifications when a waiver is about to expire. If you get a notification, that means your development team is about to be blocked, and it’s time to review the waivers.
Second, and also new in 205, is the ability to renew waivers. This way, rather than recreate waivers every time you expire, you can quickly “add more time” to existing waivers. This should help reduce the length of time that developers are blocked.
Now for the advice. It sounds like you’re blocking everything by default and using waivers to create a temporary allowlist. I understand the instinct, but that method will always always result in developers occasionally getting blocked.
Instead, I’d encourage you to try the reverse. Instead of using waivers to create an allowlist, use Firewall and policy to create a blocklist. That approach reduces friction/disruption in your pipelines while still protecting your developers from components that you decide are too risky.
If traceability is an absolute must, then consider Lifecycle as a solution or start generating SBOMs with every build.
Thank you very much, Jonathan, for your prompt response.
The new updates are excellent and very helpful to us.
Currently, our organization is being blocked by critical vulnerabilities. We manage over 30,000 libraries, so generating a blocklist is not feasible. Is this the case based on the recommendation provided?
We have considered creating a new Nexus repository exclusively for this application. Is this a viable option?
Thanks again.
Regards.
You don’t need a unique Nexus Repository for that application. You only need a unique proxy repository inside Nexus Repository. We usually recommend that each development team/application have its own unique proxy and hosted repository nested inside of a group repository. When each application has its own proxy repository, you can trace component usage easier and customize what Firewall blocks for each application.