SonarQube is one step in identifying common tech-debt, like code-smells or code-complexity, duplicate-code and lack of test-coverage.
The second step is like Kate Paulk suggested to talk the developers as they know where they took shortcuts, build quick-hacks or what the unmaintainable parts of the code are.
Log tech-debt and make it transparant:
Our team has a list of tech-debts on our wall. It contains code clean-up todo's. Going from removing sleeps from test-code, upgrading libraries, but also refactoring a class because it hard to understand. If you team does not record tech-debts I would suggest to start to create awareness as well. SonarQube alone is not enough.
The business should have a fair view on what technical issues need to be resolved in the future. Releasing features quick to make a milestone (pitch, demo, contract) is good if your business depends on it, but always take note of how this will effect in the long run. You will go slower and slower if your team goes from hack to hack to get shit done too quickly.
If you're an Agile team add the tech-debt to the backlog to make it visible and transparent. Just like with defects I would advice a zero-tech-debt policy.