Hi everyone! I've been tasked with getting Mend (I still think of it as WhiteSource sometimes, sorry!) set up with our Azure DevOps pipelines. My team wants to start catching security vulnerabilities in our dependencies as part of our CI process.
I've looked at the official docs, but I have to admit, I'm feeling a bit lost. There seem to be a few different ways to do it? Some people talk about a dedicated extension from the marketplace, others mention adding a build task directly with the Mend scan. I'm not sure which path is the "standard" or most straightforward for a beginner.
Could someone walk me through the basic, step-by-step approach that worked for them? I'm especially fuzzy on:
* Where exactly do I put the Mend API key in Azure DevOps? Is it a pipeline variable or a separate service connection?
* What's the simplest task or script to actually run a scan on a .NET project?
* How do you usually handle the results? Do they fail the build automatically, or is it more of a report?
I'm hoping for a "here's how you get from zero to a working scan" kind of guide. Our main goal right now is just to see the reports and get alerts, not necessarily block every build (yet 😅). Any tips or pitfalls you ran into would be super appreciated!
Hey, we went through this exact setup a few months ago and the official Azure DevOps extension from the marketplace is definitely the easiest starting point. It handles the task setup for you.
For your specific questions: you add the Mend API key as a *secret pipeline variable*, not a service connection. The extension's build task will reference it. The simplest scan for a .NET project just needs that task in your YAML after the restore/build steps. It automatically runs the scanner on your solution file.
By default, it won't fail the build. It generates a report and you can view the results in the "Extensions" tab of your pipeline run. You can later set a policy in Mend to fail builds on high-severity issues, but starting with just reporting is the way to go - less stressful for the team while you're learning the tool.
Totally get the feeling of being lost in those docs, happens to me all the time with new tooling. The marketplace extension is the way to go for your first run, just like user896 said.
One thing I'd add from our experience: make sure your API key secret variable is named exactly what the task expects, I think it's `wsApiKey` by default. If the names don't match, you'll get a vague auth error and waste an hour like I did 😅
Starting with reporting-only is smart. Once you've got the scan working, you can tweak the task parameters to set a vulnerability threshold for failing the build, but get the data flowing first. Did your team decide which repo to pilot this on?
Agreed on the variable naming pitfall. While the extension defaults to `wsApiKey`, I've seen teams standardize on a different name for organizational secrets. You can override it in the task configuration using the `apiKey` parameter, which adds a layer of indirection and can simplify secret management across multiple pipelines.
On the topic of starting with reporting, I'd add a quantitative note. Let the scan run for a full sprint cycle before enabling any build-breaking policies. This gives you baseline metrics, like average vulnerabilities per build, which you can later use to set a meaningful, data-driven threshold rather than an arbitrary one.
numbers don't lie