Hi @RHwang124158 (Community Member)​,

Thanks for your question. I understand where you are coming from with your workflow needs and that you would prefer to mitigate flaws via code. The Veracode Platform does not currently support working like this, however you can mitigate flaws directly from within your IDE using the Veracode IDE Plugin. You can find some documentation in the Help Centre (https://help.veracode.com/r/improve_mitigation) to get this set up.

The reason we formalise the mitigation process is because for a large number of our customers they have a dedicated security team that would review mitigations that have been proposed. They would then accept or reject those mitigations based on their acceptable risk tolerances. As such these teams may be unfamiliar with working directly on, or have access to the source code, and so this process is done via the Veracode Platform. Furthermore, the mitigation process documents a conversation between the developer and security team which is audited and can be used for compliance reasons. As such it would not be suitable to maintain such a conversation within code comments.

I recommend for compliance reasons and to help mitigate insider threats and produce a more secure product, you may wish to review who has the authority to accept or reject mitigations, which should typically not be done by the same development team. Perhaps someone outside the development team, such as QA or a manager could take on this responsibility. The same team will be more likely to accept mitigations rather than challenge them, which would be in the best interests for security purposes.

I hope this has been useful to you.

Thanks,

Anthony Fielding

Hi Anthony,

Thanks for the quick reply.

We are running a cross-functional team (I don't want to say DevOps as it's much more than that) with devs, ops, testing, security and compliance being part of the team. Everyone swarming around a PR to review it to get through to production.

Also, adding a comment at EOL is the same as mitigate directly via a plugin? It's all driven directly from the editor where the code is (and the code and therefore the repository is the single source of truth). Being able to do so without switching to another tool will reduce our cycle time which is an important aspect.

I fully acknowledge that we may be the odd one out at this point in time but if it's at all possible please add the feature - I understand that Veracode is a leader in this field and as such I truly believe it'll serve you well by doing a bit of forward thinking and support a pull-request-centric workflow (scan at pull request time, report to pull request etc) and resolvable via mechanism suggested above.

Further given how configurable veracode seem to be, it could be a feature that the security department can toggle on/off (even per repo for future enhancement)?

Thanks for listening - there are many open source products out there similar to Veracode and I would love to see Veracode being the best there is!

Ray.

Hi Ray,

Swarming around PRs sounds to be highly productive, I can imagine you must have rapid cycle times working like this and that your team is 'well gelled' to be this effective.

We support automatic pull requests for GitHub and GitLab as documented here (https://help.veracode.com/reader/hHHR3gv0wYc2WbCclECf_A/tc5UaiOlOWTfSuEV3mj4WA), perhaps that could be of use to you, also if you haven't already discovered our Pipeline Scan offering (https://help.veracode.com/reader/tS9CaFwL4_lbIEWWomsJoA/ovfZGgu96UINQxIuTqRDwg) this could potentially enable you to move faster still?

The Ideas section within the community (https://community.veracode.com/s/ideas) would be a great place to put these thoughts. I appreciate you want this functionality and I also want the Veracode Platform to continue to improve. If there is demand from other users it would help Veracode determine if this is something we need to build so I recommend visiting that section of the site.

Thanks,

Anthony