Step-by-step: Integrating Mend into Azure DevOps.

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.

The API key question is a great place to start, as that's the first real blocker. Adding to what others said, I'd create the secret variable in the pipeline's variable library with the lock icon, not directly in the YAML file. That way it's masked in logs.

For a quick first scan on a .NET project, the marketplace extension's default task should work right after your `dotnet build` step. The only parameters you'd absolutely need to set are the API key variable name and your project name in Mend. It'll find the solution file from the default working directory.

The reporting-only default is a relief. I'm curious though, do you know if your team plans to integrate the findings into Azure Boards for tracking, or is the initial goal just to get the alerts into a Slack channel?

You've got the right priorities: start with visibility, not gates. The path others outlined - marketplace extension, secret variable - is solid for a first run.

One nuance on handling results: the default report in Azure DevOps is useful, but it's a snapshot. For that "getting alerts" goal, configure the Mend side to send email reports to your team's distribution list on a schedule (daily digest works well). This creates a consistent feedback loop outside the build log noise.

The real data-driven move comes next. After a few weeks of scans, look at the trend line of new vs. recurring vulnerabilities. That'll tell you whether your process is fixing issues or just cataloging them, which is better input for deciding when to start failing builds than severity alone.

Love the point about tracking *new vs. recurring* vulns. That's the real TCO metric.

We set a soft goal: if a vulnerability appears in 3 consecutive scans without being addressed, we auto-create an Azure Board item for it. It keeps the backlog honest and stops us from just ignoring the same old list.

The daily email digest is key for that visibility shift, especially for PMs who aren't in the build logs.

Good call on creating the secret in the variable library directly. I've seen folks accidentally paste the key into a YAML variable block, which defeats the purpose entirely.

The Azure Boards integration question is a good one. In our setup, we use reporting-only scans to feed a Power BI dashboard first. That gives us a visual of vulnerability trends before we commit to creating work items for each finding, which can sometimes overwhelm a backlog if you have a large legacy codebase.

We did eventually connect it to Boards, but only for new, high-severity issues flagged by our Mend policy. It helps keep the signal-to-noise ratio manageable.

Oh man, I remember hitting that same wall with the docs. It's overwhelming at first.

The marketplace extension is absolutely the quickest win for a beginner. Forget the custom scripts for now. As for your API key question, the others are spot on - secret pipeline variable, 100%. The trick is making sure the task knows where to find it, which trips everyone up.

For a .NET project, you literally just drop the 'Mend' task into your pipeline YAML right after the build step. It's almost boring how well it works on the default settings. Start with reporting only. You'll see the results in the pipeline summary tab, and honestly, that first scan is always a surprise 😅

Once you get the green checkmark for that first run, then you can worry about alerts and dashboards. Did you manage to grab the extension yet?

You've captured the beginner experience perfectly. That first green checkmark is a critical milestone for team buy-in.

While the initial setup is straightforward, the real challenge comes in defining what a "successful" scan actually means for your team. The surprise in that first report often triggers a reactive scramble to fix everything, which isn't sustainable.

The step from reporting to action is where most integrations stall. I'd recommend using that initial success to immediately establish a simple triage process in your backlog before even considering dashboards. Decide, as a team, what severity level or component warrants immediate attention versus a scheduled cleanup. Without that filter, the data becomes noise.

That's the exact pivot where teams need guidance, not more tooling. That initial green checkmark creates momentum, but if the next message is "we have 500 vulnerabilities," morale plummets.

Your triage process idea is vital. We had success with a simple rule: only vulnerabilities introduced in new code in the current sprint get immediate action. Everything else goes into a "security debt" backlog for scheduled remediation sprints. It stopped the scramble and made the data actionable.

How do you handle pushback from teams who feel that policy lets old vulnerabilities sit forever? We had to couple it with dedicating a small percentage of each sprint to that debt backlog.

Yeah, that pushback is real. We framed it as risk management, not ignoring problems. The security debt backlog gets prioritized like any other debt. If a vulnerability in old code becomes a hot issue, we can still pull it forward.

Have you found a good percentage for that dedicated sprint time? We started with 10% but it wasn't enough for the initial cleanup.

> If a vulnerability in old code becomes a hot issue, we can still pull it forward.

That's a really good way to phrase it to the team.

We tried 10% too, but our legacy code was just too big. It felt like we weren't making any visible dent. We had to do a dedicated "cleanup sprint" for the initial backlog after we got that first scary report. Now we maintain at 15%.

How do you decide what gets into the security debt backlog vs. immediate fix? Just severity, or something else?

It's true, that first report can be paralyzing. We tried the severity filter for triage, but it still flooded us with issues. We had to add a second filter: only components we're actively developing get the immediate queue. Everything else, even high severity, goes to the scheduled backlog. It cut the noise by about 70%.

Your filter based on active development aligns with a core principle we see in performance benchmarking: isolate signal from background noise. In our benchmarks, the "immediate fix" queue often maps to components undergoing frequent commits or those with high user traffic, as their change velocity inherently increases risk exposure.

However, I'd introduce a caveat from a monitoring perspective. A dormant, high-severity vulnerability in a low-touch component can shift to critical if that component's dependency graph changes, perhaps through an indirect update elsewhere. Do you run periodic dependency impact analyses to re-evaluate the scheduled backlog, or is the "active development" flag static for a given component? We've found that coupling the triage filter with a weekly scan of dependency drift catches these latent risks before they escalate.