godojo is using hard-coded passwords rather than generating new ones

<life-advice> First, I've been doing open source since the late 1990's and something you should know is the above is no way to inspire change in software - it doesn't matter if it's commercial, open source, or 3rd party contractor developed. The expression "You'll catch more flies with honey than vinegar" comes to mind.

Reasonable empathy is even more important if you're in an AppSec team. I've 'done AppSec' at Rackspace (ran the Product Security team), Duo Security, Pearson, etc. Throwing devs under the bus as your intro to getting a problem solved generally makes things far worse, even if the issue you raised gets addressed. You may be frustrated but sharing that frustration isn't generally productive.

Also: "I expect to have to tell offshore teams not to use hard-coded passwords. Do we really need to tell the DefectDojo devs they should not use hard-coded passwords?" (emphasis is mine)

I don't even know how to address this and am at a loss about why the location of a human has anything to do with someone's expectations for them or how they should be treated.

<\life-advice>

On to the specific issue you raise...

There is an embedded dojoConfig.yml built into every godojo binary. This was done for several reason:

(1) People don't have to hand-craft that yaml file - considering it's length, that would be a nightmare. (2) I don't have to ask users to download a config file and godojo when they want to do an 'iron' install (3) The dev install type has known, predefined values based on that embedded dojoConfig.yml which makes dev/QA work easier and more consistent. (4) All people need to do if they want repeatable, secure installations with godojo is create a dojoConfig.yml that suits them and store it appropriately. (5) For more sophisticated users, godojo supports things like pulling secrets out of something like Hashicorp's vault and passing in secrets as ENV variables. (6) The embedded config supports the regrettable but inevitable use-case of 'download something, run it and expect it to work'. I'm not particularly fond of this use-case but have seen enough issues submitted to projects by people who don't RTFM that there's a strong desire to meet that use-case if only to keep non-actionable issues out of the system.

The expectation that the dojoConfig.yml file is customized/updated by the person running the installer is clearly presented in:

(1) The README of this repo

None, just download the most recent [godojo release](https://github.com/DefectDojo/godojo/releases) and either:

1.  Accept the default configuration (one will be created for you the first time you run godojo)
2.  Edit dojoConfig.yml to meet your needs then run godojo
3.  Set environmental variable(s) to override the default configuration in dojoConfig.yml when you run godojo

(2) The output of godojo when it extracts the embedded config on first run:

./godojo 

NOTE: A dojoConfig.yml file was not found in the current directory:
    /home/example
A default configuration file was written there.

Please review the configuration settings, adjusting as needed and
re-run the godojo installer to begin the install you configured.

I guess I could put a huge warning at the top of the embedded dojoConfig.yml or maybe move the more sensitive config items to the top and re-arrange the struct I parse that yaml into but if people choose not to follow directions and take ownership of their use of software, there's not much anyone can do.

Perhaps some rephrasing of the instructions in the README would be helpful - I'll look at tweaking that to make it more clear that, unless you really don't care about security, you need to adjust these (enumerated list) of config items. Added that to the refactor TODO list...

DefectDojo / godojo

godojo is using hard-coded passwords rather than generating new ones #56