MClarkson676368 (Community Member) asked a question.
Adoption of/Increasing usage of IDE-Scan (Greenlight) amongst developers
How are community members handling deployment of/usage of IDE-Scan (Greenlight)? Do you mandate its usage at a policy level with some supporting governance mechanism etc?
We are having difficulty in trying to increase it's usage. We have held several onboarding workshops with our dev teams run by our Veracode SPM, but this has failed to increase usage.
Has anyone looked at some form of automated deployment, the issues with the Veracode Identity REST API not withstanding?
Would love to hear what's worked in your organisations.
Thanks,
Michael
.png){kind=logo}
@MClarkson676368 (Community Member) this is a great question. The simple answer is to get buy-in from upper management. Greenlight is very effective tool for catching bugs early on in the development process which is a core concept of shift left. Perhaps, introduce them to shift left?
Second @EGertis462759 (Community Member) 's point about the idea behind IDE Scan (Greenlight) being "shift left." Here's a blog post about how you can help shift security left in your organization.
What is the impact of failing the Veracode Policy scan in your change management process? Everyone in this forum understands the importance of finding vulnerabilities and fixing them, and I'd say even most of the developers in your organization do too. However, a dev team is given a list of features by the product teams that need to get created in a given time frame. This leaves little room for a dev team to work on technical debt.
If you can get the product side of your organization to understand the importance of fixing security findings they will be more likely to allow the dev teams to work on the vulnerabilities. When that happens the dev teams will want to find the vulnerabilities faster and that's where things like Greenlight and the Veracode Pipeline scanner can help.
One way to get product to buy in is to halt code promotions to production when the application does not have a passing policy scan. That's pretty heavy handed to roll out at once, so if that is not the case already in your org you could make an announcement that this new policy is rolling out that will impact change requests. It should light a fire under most of the groups. Then you can work with them and keep pushing the deadline back until you have enough buy in.
Another way you could get the GreenLight buy in is to start a Security Champion Program. For this program you can hand pick or have volunteers from the key development groups in your org. These champions will be the liaison between your appsec team and the dev team (so it helps if that person is interested in security). With this person you can train them using the Veracode training material, invite them to the Veracode coding challenges that are hosted here in this forum, and teach them how to use the security tool you have in your org. That way when they reach back out to their colleagues they have new tools to show them and they can get buy in for you rather than your team preaching from the mountain top.
As teams would bring projects to what we called an Architecture Review Board that required new apps to come before the board before they begin development work. There we had the chance to encourage Sandbox scanning and the use of IDE Scanning to get to the point where defects are caught and fixed as closely to the point of where they're introduced. As people buy into this notion and begin using IDE scanning, they tend to become the BEST salespeople for it to others on the same and adjacent teams. We also offer simple instructions (on the Confluence internal How to Use Veracode site we maintained). Once people see it, they want it. The trick was getting them to see if the first time...