3 ms·

I have no idea how their team was composed previously, but it could be that they had a lot of folks who were analysts but weren't contributing much to remediati

I have no idea how their team was composed previously, but it could be that they had a lot of folks who were analysts but weren't contributing much to remediating issues. It sounds like (and I have no idea again) that they're hiring a small number of security engineers (maybe even one) to not only actively look for security issues, but to also actively work to remediate them and improve code security posture as well. This function paired with a specialized external team to handle general SOC/network level security probably is a smarter investment for them right now. > You may say "we will get an external team to do this", but will they get access to source code? Will they get access to upcoming features? Most likely yes in my experience.

bArray 4y ago
> but it could be that they had a lot of folks who were analysts but weren't contributing much to remediating issues. Neither feature testers (does it behave as expected) or security testers (is it secure as it does it) are expected to write fixes. Writing fixes needs to be planned in the sprint and is better worked on by an expert on that system. > they're hiring a small number of security engineers (maybe even one) to not only actively look for security issues, but to also actively work to remediate them and improve code security posture as well. If this is true, it could seriously affect their ability to ensure the system remains secure. Sometimes a security issue will take a long time to hunt down, and perhaps require a large rewrite to deal with it. Whilst this person is dealing with this, they are no longer looking for new issues. I'm just not sold this is anything but a cost cutting exercise, and could (theoretically) lead to bad practices in the future.
- jeremymcanally 4y ago
  > Neither feature testers (does it behave as expected) or security testers (is it secure as it does it) are expected to write fixes. Writing fixes needs to be planned in the sprint and is better worked on by an expert on that system. ...on teams that are structured that way. That is far from a universal thing. But, yes, I'm with you that it could be just cost cutting or something weird with the team pushing back on some things. As I said, I have no idea, but there are universes where it makes sense to make those changes.

bArray 4y ago

> but it could be that they had a lot of folks who were analysts but weren't contributing much to remediating issues. Neither feature testers (does it behave as expected) or security testers (is it secure as it does it) are expected to write fixes. Writing fixes needs to be planned in the sprint and is better worked on by an expert on that system. > they're hiring a small number of security engineers (maybe even one) to not only actively look for security issues, but to also actively work to remediate them and improve code security posture as well. If this is true, it could seriously affect their ability to ensure the system remains secure. Sometimes a security issue will take a long time to hunt down, and perhaps require a large rewrite to deal with it. Whilst this person is dealing with this, they are no longer looking for new issues. I'm just not sold this is anything but a cost cutting exercise, and could (theoretically) lead to bad practices in the future.

jeremymcanally 4y ago
> Neither feature testers (does it behave as expected) or security testers (is it secure as it does it) are expected to write fixes. Writing fixes needs to be planned in the sprint and is better worked on by an expert on that system. ...on teams that are structured that way. That is far from a universal thing. But, yes, I'm with you that it could be just cost cutting or something weird with the team pushing back on some things. As I said, I have no idea, but there are universes where it makes sense to make those changes.