Compliance checks have improved while vulnerability coverage and SBOM accuracy still need workI think Black Duck SCA needs to improve on the overall approach. I assume that the people who developed Black Duck SCA believe that users will use this tool for some time in a full-fledged way with all those features. However, the way it really works with product development or in a software development life cycle is that this is just one of the steps for checking whether something is license compliant, whether it has vulnerabilities, or whether the SBOM is generated. It is just one of those steps in the software development process. The expectation from the tool's perspective is that users have to go into the Black Duck SCA portal, look at each of those items, and if something is not correct, try to find it out and update or configure the right CPEs or PURLs or those kinds of things. In reality, most users would not have time for this because they would have done this as part of the build and would generate an SBOM as part of the build. The tool should be quite usable. If a feature works properly and correctly, then nobody will go back and try to spend time on that. For example, if I generate an SBOM and that SBOM has a particular CPE and there are multiple sources, the tool should produce those CPEs with vulnerabilities, put them into the SBOM, and allow me to move forward. If there are more bugs or more configuration requirements, the usage will come down. It is like a mobile application: if there is too much data that needs to be looked at, configured, and used, then the number of users would come down. The tool should be fast, usable, and accurate. Users should just be able to use it without needing to learn too much. The learning curve should be less when using a tool, and the usage should be easy with basic understanding. They should not need to go through complex processes and can assume that whatever data is given is correct. That is where the whole problem with Black Duck SCA lies. The documentation is not really on the mark. For example, if there is a functionality, such as wanting to see a CPE, the documentation should show how to get this via API or see it and how to configure that with examples. Most of the time the tool says it is all in the community, which is not ideal. The community is different from a conceptual view. The community is for bugs and issues that users want to report. However, people who are looking at the tool fresh and need to see functionality such as scan configuration need clear documentation. If I want to see the scan configurations and how to do it, there are videos, but there should be clear documentation with examples, such as how to configure for Docker using specific commands and methods. This example could be clear documentation and should not be redirected to the community every time. If there is a problem or those kinds of issues, they should go to the community and solutions will be found. However, for basic documentation on features being provided, I do not see that kind of clear documentation with clear examples.
