Generated BuildAndPublish.yml incorrect OWASP settings

[refactorinc]

Describe the bug The generated BuildAndPublish.yml includes an OWASP check run; but it does not have the setting owaspDependencyCheckVersion: '7.4.4' Currently this is a hard requirement. Without it, the build will fail by design before any code is even compiled.

To Reproduce Steps to reproduce the behavior:

1. Create blank solution
2. Do a guidance solution generation
3. Commit & push
4. Create a build referencing BE/Yarp/BuildAndPublish.yml
5. Run the build

Expected behavior The OWASP checks succeed and the build moves to the 2nd stage.

Desktop (please complete the following information):

• Visual Studio Version 17.4.1
• Guidance Version 2022.2.1.11

Additional context Generated code shouldn't require this level of modification by each architect for each project for each generation to get something to work

[HaGGi13]

This is correct, because we want to use the latest version by default, but at this point in time it's needed to pin the version to 7.4.4 until we have a clean solution to migrate/use the latest v8 of OWASP DC. Unfortunately we have to find a solution, due they changed the local database format that results in issues if files of the old version still exist in an old analysis folder that is reused for a next analysis.

Therefore, I vote to do not include this fixed version configuration, because as soon as we use the latest version again, we have to modify the file again or we have the risk that it's never updated by the architect/developer to the latest version and the 7.4.4 is used forever - not by intension, but by accident.

Fix the version (add this entry) manually is done in less than 10s.

[refactorinc]

This is correct, because we want to use the latest version by default, but at this point in time it's needed to pin the version to 7.4.4 until we have a clean solution to migrate/use the latest v8 of OWASP DC. Unfortunately we have to find a solution, due they changed the local database format that results in issues if files of the old version still exist in an old analysis folder that is reused for a next analysis.

I prefer to have 'by default' something that works. Today this is not the case.

Therefore, I vote to do not include this fixed version configuration, because as soon as we use the latest version again, we have to modify the file again or we have the risk that it's never updated by the architect/developer to the latest version and the 7.4.4 is used forever - not by intension, but by accident.

This is already the case today when we must manually add the mentioned setting. Having the guidance add the setting automatically will not change this aspect.

Fix the version (add this entry) manually is done in less than 10s.

After 3 months and 3 days I suspect we have surpassed this.

[refactorinc]

Therefore, I vote to do not include this fixed version configuration, because as soon as we use the latest version again, we have to modify the file again or we have the risk that it's never updated by the architect/developer to the latest version and the 7.4.4 is used forever - not by intension, but by accident.

My issue is that out-of-the-box the build does not work. Following communicated workarounds, today this is a bug in the guidance.

If another workaround can be found that does not involve the guidance then the issue behind this bug will be fixed and this bug will be nullified.

Because you express concern regarding all the modifications needed to undo hard-linking all projects to 7.4.4, I think for example to hard-coding the version on the main branch of the referenced devops repo. This way you have global control of the version used and the projects are freed from the workaround.

[rdarko]

this unforunately wont be done, because we fear that 7.4.4 will never be updated from the architects to the latest available version as soon as its supported by build templates

[refactorinc]

Sorry but it's configured as a remote repository. You can perfectly set the 7.4.4 as default value in the BuildAndPublish.yml who is automatically re-downloaded for each build.

When finally a version >7.4.4 is working you can modify the default value. This way each and every project will automatically follow on their next build and finally you take control over which version is used.

Please re-open.