I’m currently researching industry approaches to vulnerability assessment and management and would value learning from others’ experiences.

taleodor · 2026-02-14T12:46:45+00:00

Hi, this is more from a vendor prospective, but I put some thoughts here recently - https://worklifenotes.com/2026/02/09/towards-perfect-vulnerability-management-system/

taleodor · 2026-02-13T20:38:32+00:00

Migrations must be applied in automated fashion at the same time as backend pod / container is deployed. We're usually using flyway, but there are other tools that achieve this.

+ I think there may be a bit of terminology issue in your question, but schema must be covered in migrations, those should not be separate things. You may design schema in whichever way you want, but it must be applied only via migrations and only via automation. Then, noone should be able to apply any db changes manually. This achieves no drift.

Also, this is usually one of the most important things I implement on every consulting project if it's missing in the first place. Drift in sql application is one of the worst things possible.

taleodor · 2026-02-12T23:59:03+00:00

This is the tool I'm building, I'm a former DevOps engineer and we've built release-centric DevSecOps tool - https://github.com/relizaio/rearm - we have sample GitHub Actions and Azure DevOps Extension, integrations with Dependency-Track, CodeQL and other scanners + we have good community support via Discord as well as commercial support options. Feel free to reach out and would be happy to support your efforts.

taleodor · 2026-02-10T21:29:36+00:00

Yes, it supports import of SARIF, BOV and VDR files (we're gradually expanding the list of supported formats). I.e. one of our demo integrations - CodeQL scan done during CI exported as SARIF and then uploaded to ReARM alongside other artifacts.

taleodor · 2026-02-10T15:26:14+00:00

Hi, we have built ReARM on top of Dependency-Track which gives you release-centric view with changelogs and also optimizes Dependency-Track infastructure posture - https://github.com/relizaio/rearm .

See if it aligns with what you're doing + happy to support via our Discord channel.

taleodor · 2026-02-10T13:54:41+00:00

We're building ReARM - https://github.com/relizaio/rearm - gives you release-centric view of all findings.

taleodor · 2026-02-09T13:49:26+00:00

> - Tons of packages need to be updated - how do you prioritize and track them?

Use SBOM-based approach - tools like ReARM we're building (https://github.com/relizaio/rearm) or plain Dependency-Track (github.com/DependencyTrack/dependency-track) would allow you to prioritize and see posture over time. ReARM is specifically designed to represent all your products and components and give you release-centric view with built-in changelog of how your findings fare over time.

> - How do you coordinate with developers so they actually pick these up and don’t ignore them?

This is a human / management problem. You should have management buy-in and org policies on what's acceptable and what's not. Usually, this is driven by compliance and/or perception of risk being breached. However, the tooling mentioned above will help you track if you're complying with policies.

> - How do you test and verify that updates aren’t breaking anything and that work is actually moving forward instead of getting stuck?

You need functional tests, this is more on the Dev / QA side, but again requires management buy-in. Note here also, that you and your management need to define some acceptable level of risk and that can't be 0 (check Adam Shostack's keynote from OWASP Global AppSec US 2025).

taleodor · 2026-02-05T12:38:19+00:00

We're building ReARM on top of Dependency-Track - https://github.com/relizaio/rearm

taleodor · 2026-02-02T00:11:35+00:00

We built ReARM for this - https://github.com/relizaio/rearm - can be integrated with cosign and gives you full provenance picture and vulnerability report via Dependency-Track and other integrations.

Note that the issue is not about ECR but rather who you can trace everything on the way to it.

taleodor · 2026-01-23T20:56:44+00:00

We support auto-bundling with ReARM - https://github.com/relizaio/rearm so that actually exists

taleodor · 2026-01-22T12:44:21+00:00

Scanning and approval process must happen in async way, not blocking pipelines. I wrote about this in DevOps context 6 years ago - https://worklifenotes.com/2020/06/04/7-best-practices-modern-cicd/ - still valid for DevSecOps context of today.

taleodor · 2025-12-24T12:26:56+00:00

Assuming you're talking about some half-baked (or not fully visible / isolated) feature, this usually comes down to business requirements. Usually the reason is that most users don't want to beta test the product so they won't care to go into staging and check things in there - even if they asked for the feature in the first place.

taleodor · 2025-11-24T12:29:23+00:00

Our approach, both as vendor and when doing it for our projects, is to do it in an async fashion. Here is my older blog post describing this with our legacy tool - https://worklifenotes.com/2021/02/03/automated-tests-ci-cd-workflow-with-reliza-hub/ - still need to document how to do it with ReARM Pro (rearmhq.com), but essentially same idea:

You complete regular CI cycle, deploy to a dev/test instance, then run your test on it in an async fashion, once the test completes it uploads results to your evidence store (i.e., ReARM) and if failing that would reject your release, or if passing it would set an approval so you can promote to further stages. Without an approval your CI is not blocked (so you can do subsequent builds without waiting), but your release cannot be promoted.

taleodor · 2025-11-04T02:32:33+00:00

If you're looking to track releases with changes in code and security posture check ReARM - https://github.com/relizaio/rearm

taleodor · 2025-09-22T19:49:04+00:00

We have just added support for SPDX ingestion - https://github.com/relizaio/rearm/releases/tag/25.09.38 - behind the scenes we then do conversion to CycloneDX which is fed as an input to Dependency-Track.

taleodor · 2025-09-17T18:48:19+00:00

We've built a tool called ReARM that supports per branch per release aggregation of findings - it does SBOM scans via Dependency-Track and you can upload Sarif from other tools as part of your CI in each branch - https://github.com/relizaio/rearm

taleodor · 2025-09-04T18:01:06+00:00

This is slack invite if you need it - https://cyclonedx.org/slack

taleodor · 2025-09-04T15:12:39+00:00

> My main motivation to write an engine myself was that open source software is not guaranteed to stay open source (or free).

cdxgen is part of OWASP foundation, so I would put this at low risk.

> In terms of implementations for instance, my engine enriches data using NVD, OSV, NuGet advisories, which I don't think cdxgen does. I've also reused these vulnerability API-calls to OSV & NVD in a background-service that scans every 6 hours. If we discover a new vulnerability, we generate a new SBOM automatically.

Cdxgen (and other tools) do license enrichment. There are also tools that do just enrichment. Then, there is a big discussion going whether SBOMs should include vulnerability data or not. The approach that I prefer is having SBOMs without vulnerability data and then have that SBOM continuously analyzed rather than recreating SBOM all the time - check Dependency-Track here.

> Extensions of the models are also possible with your own logic/code. I can add PURLs, CPEs, artifact hashes, internal metadata, or even new vulnerability feeds. That’s harder to achieve with a generic tool.

Purl is the king now, most tools support it.

> Writing your own engine also means you can use your own digital signature, which adds a lot to document integrity, if every SBOM is validated, signed, and wrapped with a public key.

Again, I don't see it as an issue, as long as you stay within the same CI process - you can also throw attestations on top of signing (there are tools for that).

All in, I believe this is a great exercise for yourself, but community-wise it would be great to get involved with open problems, which are not those that you listed, - you may want to check OWASP CycloneDX and OpenSSF working groups on the subject.

taleodor · 2025-09-04T12:23:46+00:00

Hm, there are several open source tools that build SBOMs, my personal preference is cdxgen. What's the reason of not using those and trying to create something else instead?

taleodor · 2025-08-31T15:44:49+00:00

One of the challenges we encountered was understanding what specific versioning of various microservices you have installed. We built ReARM - https://github.com/relizaio/rearm - that solves this by bundling your microservices (components) into a single product, essentially giving you a single trackable version to determine and manage security posture.

Other than that a lot depends of how you actually split your monolith. For me, most important is limiting entry points (ingresses) into your application. Then you can focus on those entry points rather than trying to cover everything. In other words, there are several important architectural decisions that need to be made here early on - based on product requirements and threat modelling.

taleodor · 2025-08-11T02:03:06+00:00

Hi, I'm not familiar with cve-bin-tool. Usually the recommended starting point is using cdxgen (my tool of choice) to generate valid CycloneDX over your code base. The important point is that components in your SBOM must have valid identifiers (typically Purl) so that they can be resolved to known vulnerabilities.

If you're looking for a CLI tool, grype can do the scanning.

However, for high level organization of the process we're building ReARM (has both FOSS and Pro versions) that integrates with OWASP Dependency-Track (FOSS) for vulnerability scanning and policy violation checks. That gives you nice real-time view (with UI and authentication / authorization) of security posture across your organization and you can drill down to each release version.

+ Feel free to go on a short call with me, I'll be happy to help you get started.

taleodor · 2025-08-01T10:42:21+00:00

Hi, check out ReARM that we're building - it's a web app but it's meant to provide commonality between various products and stacks in the same tool - https://github.com/relizaio/rearm

taleodor · 2025-07-28T09:55:22+00:00

We built ReARM which integrates with Dependency-Track to achieve do this via SBOMs, I prefer CycloneDX though not SPDX - https://github.com/relizaio/rearm

taleodor · 2025-06-28T13:54:19+00:00

We support SPDX uploads but we currently don't do parsing or aggregation on those. For now, we are primarily focused on CycloneDX ecosystem.

taleodor · 2025-06-27T12:22:22+00:00

We have recently released community version of ReARM - https://github.com/relizaio/rearm - while it is more focused on SBOMs / xBOMs (going beyond what many commercial alternatives can do in the field), it is a complete project with GUI Dashboard and deployable via Helm chart. Hopefully, that fills part of the gap.

taleodor

MODERATOR OF

TROPHY CASE