Yes, excluding the virtualenv folder does blind you to library security issues. The free tier creates a difficult trade-off between scanning your own code and your dependencies.
I track this for my projects in a small spreadsheet. A Flask app with only Flask and SQLAlchemy in its virtualenv might add around 15k lines to the scan. That's a significant chunk of the 100k LOC allowance, but it may be worth it for the dependency check. Adding a larger framework or utility library can easily double that.
The pragmatic choice for a side project is often to exclude dependencies and handle their security updates separately via tools like `pip-audit` or GitHub's Dependabot in your CI, before the code even reaches SonarQube.
Measure twice, buy once.
Totally agree on tackling critical vulnerabilities first. It's the only way to stay sane with a legacy codebase.
I've found the "fix as you go" approach works best when you sort by severity and then by file modification date in the SonarQube UI. That way, you're always hitting the fresh, high-priority stuff in the files you're actually working on.
Data is the new oil - but it's usually crude.
Yes, it will count everything in your scannable directories, including `node_modules`. That's an easy way to blow through your limit before you even see your own code.
You need to set up exclusions in your analysis configuration. Look for the `sonar.exclusions` property. For a JS project, you'd add `**/node_modules/**` to that list. Just be aware you lose the ability to see security issues in those dependencies.
If dependency scanning is important to you, you'll hit that ceiling fast. The free tier is really for your proprietary code only.
—hd
Yeah, that initial issue flood is rough. The free tier is okay for a single project if you exclude dependencies like others said. I'm also trying to figure out the workflow part.
>Do you fix as you go, or do a cleanup day?
I'm leaning towards a mix. I'll fix a critical bug if I see it while I'm in the file, but I save the big "code smell" refactors for a dedicated session every couple weeks. Otherwise I get stuck in endless cleanup and my feature never gets done.
How do you decide what's a "must-fix now" versus a "can wait"?
Trying to figure it out.
That mix sounds like a good plan. I'm new to this, so I worry about getting overwhelmed too.
>How do you decide what's a "must-fix now" versus a "can wait"?
I look at what the quality gate says will actually block my merge. I figure if it's stopping the pipeline, it's a must-fix. The rest I tag with a comment and come back later. Does that logic make sense, or am I missing something?