I'm going to assume that "out of control" means you don't know what OSS you have in your environment, or you aren't on top of your open-source software licensing compatibilities, or you don't know what vulnerabilities or code quality issues your OSS may have. Or a combination of these issues.
The first thing you need to know is what OSS you have. If your environment is relatively new/small, you may be able to do a manual audit to get a list of what you have. (But if that's the case, you're probably not "out of control").
For larger, more complex situations, you're going to need help, just to get a full list of your OSS components from a software composition analysis tool. The better tools out there will also tell you if you have any license restrictions or requirements that must be met. A good SCA will usually also automate managing and tracking your OSS code and help you keep up with security or compliance issues. And of course it will flag vulnerabilities and many SCA tools out there will help you fix them.
In addition to an SCA, to help keep things on track moving forward, you should think about setting up a policy for open-source usage in your org, with guidelines for selecting and using open-source components. This will require learning up and training your team on license compliance and selecting good open-source components.
When you say centralized view, do you mean different testing categories which should be looked at for matured software development? If yes, sharing my views on important ones.
1. Functional Testing (either using open source frameworks like playwright, cypress, and selenium or using a platform approach like Katalon, Tricentis, SmartBear).
2) Performance and Load Testing
3) Chaos Engineering
4) Security Testing which includes SCA, SAST, DAST, checking IaaC scripts, checking K8 clusters, docker images
5) Accessibility Testing to comply with WCAG guidelines
6) API testing
The duration of SCA scanning is going to vary depending on things like the size and complexity of the application being scanned, the depth of the analysis required, and the capabilities and performance of the SCA tool being used. That last piece can be crucial and is a good reason to do a PoC or at least some trial runs of any solution you are considering.
In general, an SCA scan can take anywhere from a few seconds to several hours or even days, depending on the size of the codebase and the scope of the analysis. However, many SCA tools are designed to optimize their performance and reduce scanning times by focusing on critical vulnerabilities first, performing incremental scans, and providing parallelization capabilities.
Speed can also depend on the stage at which you're scanning. IDE scanning is generally going to be the fastest. Shared pipeline scans will take longer and full production scans are going to take the longest.
Obviously, speed is important, but fast without accuracy isn't going to do the job, so that's another aspect to keep in mind. Over time, the number of false positives should decrease as your devs learn better coding practices and you learn to configure your scanner for your particular environment.
PeerSpot’s crowdsourced user review platform helps technology decision-makers around the world to better connect with peers and other independent experts who provide advice without vendor bias.
Our users have ranked these solutions according to their valuable features, and discuss which features they like most and why.
You can read user reviews for the Top 5 Software Composition Analysis (SCA...
The world of technology is constantly undergoing both evolutions and revolutions. It is always difficult to know just what kinds of changes and innovations each year is going to bring. The fields of Development and Operations (DevOps) and Development, Security, and Operations (DevSecOps) are two examples where the best people can do is offer their predictions of what might be in store.
PeerSp...
I'm going to assume that "out of control" means you don't know what OSS you have in your environment, or you aren't on top of your open-source software licensing compatibilities, or you don't know what vulnerabilities or code quality issues your OSS may have. Or a combination of these issues.
The first thing you need to know is what OSS you have. If your environment is relatively new/small, you may be able to do a manual audit to get a list of what you have. (But if that's the case, you're probably not "out of control").
For larger, more complex situations, you're going to need help, just to get a full list of your OSS components from a software composition analysis tool. The better tools out there will also tell you if you have any license restrictions or requirements that must be met. A good SCA will usually also automate managing and tracking your OSS code and help you keep up with security or compliance issues. And of course it will flag vulnerabilities and many SCA tools out there will help you fix them.
In addition to an SCA, to help keep things on track moving forward, you should think about setting up a policy for open-source usage in your org, with guidelines for selecting and using open-source components. This will require learning up and training your team on license compliance and selecting good open-source components.