Hi, I guess I was suggesting that yes.. but....just "thinking while typing" now... so bear with me and my darkest thoughts 🙂 this is not trivial to map. There are implici ways on how you use defectDojo, how you govern your "produt/engagement" etc. that may change how it can work. one shot linear flow:
Development cycle - lots of branches, commits, PR validations etc. -> (eventually) branch main deployed to staging.
SAST was runned and test results imported (or pushed) to dojo.
SCA runs...
secrets...
...Dast
Someone finds a bug... the thing does not move on. Go back...
New dev cycle, more SAST, DAST, ... (new imports/pushes to dojo??)
AProved... goes to prd...
OK the "last" push means PRD. But...DAST was only in staging... out of step and infra hasn't change (in this case, bear metal or vm for instance) so the previous version aplies. Now, if it moves to production you could "automagically" promote those imports to baseline... So it seems it could sort out "this view for governance" on defectDojo, But, other cenario: Development cenario. Different scanners PMD, SemGrep, SOnar... all pushing to DefectDojo. PR could check status on DefectDojo. Risk Accepted in Dojo etc. then for this the governance on dojo is diferent. and in this "branch" view would be helpful/desirable... are those 2 different view "joinable"? sorry, not much help. But I will think about this and come back.
Hi all — new guy here, so apologies if I am stepping out of line 🙂 , just testing this out really. Wouldn’t adding a strong “branch” concept on top of the already flexible model of Products, Engagements and Tests mostly benefit SAST/SCA use cases? For other test types it feels less natural. DAST baselines are usually tied to a release, environment or deployed version rather than a branch, and infra scans are often even more disconnected from development branches. So maybe instead of a “default branch”, we could think about defining a baseline import set, and then compare other runs against that baseline. In this approach:
a test import set is marked as baseline, regardless of test type
findings in the baseline represent the current product state
findings in other runs are treated as emerging issues
fixes seen outside the baseline are tracked, but would not affect the product score until that (re)import (or set of imports) is promoted to baseline
We could still support automatic baseline selection rules using metadata like branch=main, release tags, environment, etc., but the core logic would not depend on VCS concepts. We could also move most of the version/context metadata from engagement closer to the test import itself, where it naturally belongs. Just a thought — curious if this makes sense, or if there is any specific issue with branch I am missing.
