Hello everyone,
Thank you to all who attended our webinar session! You can now find here all the questions that were asked during the session, and the resources mentioned by the presenters.
Questions:
Q: Is there a big difference between SonarCloud on-prem and SonarCloud from a features perspective?
A: SonarCloud is our cloud-based managed service (SaaS). SonarQube is our self-managed product. There are some differences currently between the two products. We are working on feature parity between the two products.
Q: Regarding my source code, is SonarQube a safe tool to use?
A: Yes, absolutely. SonarQube is being used by thousands of customers globally. You have full control over your source code.
Q: SonarQube use AI for analyzing code?
A: No. We use static code analysis. The analysis results are deterministic. For .NET, we write analyzers using the Roslyn Compiler Framework and our analyzers are open-source https://github.com/SonarSource/sonar-dotnet.
That being said, you can use Sonar to analyze AI-generated code and find issues. Find more info here: More info - https://www.sonarsource.com/solutions/ai
Q: Will we see Compliance reports added to SonarCloud in the future?
A: Yes, definitely, it is on the roadmap.
Q: Do you recommend scanning the code in Pull Requests and the different environments branches, I noticed is slow scan in all of them using Enterprise Edition v9.9.5, how can this be a better practice?
A: We recommend scanning code in Pull Requests to use our "Clean as You Code" methodology of solving quality issues as soon as possible in the development workflow. For .NET, you will find some tips and tricks on performance improvements in this guide on our community forum: https://community.sonarsource.com/t/the-sonar-guide-for-investigating-the-performance-of-net-analysis/47279
If you still have problems, please open an issue on our Sonar Community forum https://community.sonarsource.com/
Q: What’s the best way to handle unit & integration tests for an authenticated application as part the CI/CD pipeline run?
A: [Damien Bowden] You can easily test. You’re testing directly against the application, and there is no security involved. There’s no problem with that for integration tests, but it’s slightly more difficult depending on what type of API you have. There are 2 different types of APIs:
- APIs for delegated user app flows.
- APIs for applications.
If it’s an API used by an application, it’s really easy to set up an integration test. Then, you test everything from the outside, including security. There are lots of examples online.
If you’re doing a delegate flow, you have to try and make a back door and, in some type, a build environment where you can allow an access token to be given to a non-delegate user, as a delegate access token should be only acquired by a user logging in. This means you have to get consent, and some human has to actually click somewhere.
If you shorten that out for integration test, where you want to test everything against the API you have to make a back door. You should be really careful that you cannot use that backdoor in a production environment, but only in your development environment. First, test from the outside including the security of the integration test against the APIs, and then you can do the whole lot into the database and backup. […]
It’s a pretty easy setup, and I’d recommend having a look at the blogs we mentioned, and trying to build it, but always have to include the security in your integration test as well, I think, because then you get the claim. […] There are no correct answers, but I try to include as much as possible when I’m doing integration tests. If something does go wrong, I’ll find it.
Q: You spoke about client-to-service authentication and authorization. Let’s say I have multiple microservices, what is the recommendation for service-to-service authentication and authorization? Which OICD flow to use?
A : [Damien Bowden] There are about 7 or 8 correct answers to that question.
First, I’d say it depends on how you set your API. Microsoft uses the “on behalf of flow”: they’re using delegated access tokens that are given to the application on behalf of that user. So somewhere up to chain, you have a user interface that logged in. It’s the best way of doing this because you’re reducing the amount of access: it does not trust the API2, just the access token. By using this, you reduce the blast radius. If you cannot do this, you can also use a Grant Exchange. Usually, you will use a Client Credentials Flow, which is an API to API, allowing full trust between two servers.
Q: Are there any advantages to using one over there in terms of SAML and openID?
A [Damien Bowden] I don’t see any advantage from a security perspective if done correctly.
Resources:
