How do you effectively scan open source software for vulnerabilities?

• Detect all the open-source components used in software project. • Use open source vulnerability scanners like Anchore, sqlmap, OpenVas or Clair to detect unpatched security vulnerabilities in these components. • Once vulnerabilities are identified, they can be fixed through patches (remediation process)

When it comes to small/medium sized infra based organizations, they often rely on OSS tools. There is a high possibility that these tools are even deployed at Prod level exposing the Production data telemetry to these tools. When it comes to detecting vulns within OSS, key factor is to prioritize the actual threat VS the low hanging fruits. Often OSS would show tons of vulns and in practical situation, one cannot patch all at a time. Basis the deployment of the OSS tools, identification of vulns would help the organization prioritize high impacting vulnerabilities. Upon identification of the crown-jewels (critical infra) - remediation actions can be segregated basis the criticality.

While applications being developed are tested by security teams , the attacks surface of an application is also a factor to the OSS used , an applicaton can be secure as possible , however since most of the development is plugged by OSS , a vulnerability to it could be leveraged for exploitation. Additionaly OSS could be prone to dependency confusions, rogue code/backdoors.

Security is a journey and should be done in a continuous fashion. It mostly depends upon the security culture and awareness in an organisation. Based on org level we should start with open source tools that are available such as OWASP Dependency track to monitory third party libraries as it does a decent job of identifying security vulnerabilities. I've observed, when any critical zero day vulnerability comes many teams lacks with mechanism to identify if zero day is affecting them or not. Detection becomes very crucial stuff when it comes to zero days. To remediate the findings coming from OSS scanning tools, it should follow regular patch and release management cycle to upgrade all 3rd party libs to latest version.

Scanning OSS is good, but may not be effective if OSS introduction is not controlled. It's difficult to remediate if your organisation have thousands of SSL libraries of different brands and versions, including some are dopped with malicious content from non-legitimate source. It a joke if your developer download a malicious version h after the current scan result indicate it contains vulnerability x. Do have a process to approve OSS before adoption, on a central registry and distribution, with proper security review, testing and recertification intervals, and threat intelligence to trigger update.

When deciding what to scan, it's essential to think beyond the surface. Look into not only the primary code but also subsidiary elements that may not be in the spotlight—config files, documentation, and less prominent modules. These elements, while seemingly peripheral, can be gateways for attackers if they contain vulnerabilities. A holistic approach to scanning will involve a combination of static and dynamic analysis tools that will work in tandem to provide a comprehensive view of potential risks.

Coding practices: Look for insecure coding practices like hardcoded credentials, SQL injection vulnerabilities, or cross-site scripting (XSS) risks. Static analysis tools like OWASP ZAP or ESLint can be helpful for these checks. Configuration issues: Ensure configurations of open-source libraries and frameworks are secure and follow recommended best practices. Specific tools might exist for popular platforms like Apache or Nginx. Outdated dependencies: Keep your open-source components updated to utilize their latest security patches and enhancements. SCA tools can identify outdated dependencies for you.

To scan open source software for vulnerabilities employ automated tools like static code analyzers and vulnerability scanners complemented by manual code review by experienced developers.

These areas can include applications, ports, websites, services, networks, and systems that are accessible to external customers or users. These scans play an essential role in identifying vulnerabilities that attackers can exploit from outside your organization.

Continuous OSS scanning is the gold standard, as dozens of new vulnerabilities are identified every day. At a minimum, companies should scan every new build for newly-detected vulnerabilities prior to moving it into production.

The timing of scans should be strategic; it should align with the software development lifecycle and be triggered by events that could introduce vulnerabilities, such as new deployments or updates. This ensures that scans are both routine and responsive, providing a safety net that evolves with the development process. By integrating scanning into the CI/CD pipeline, organizations can ensure that every change is vetted for security before it reaches production.

Scheduled Scans: Set regular scans (e.g., weekly or monthly) to catch newly discovered vulnerabilities or changes in your codebase. Triggered Scanning: After updates and upgrades: Scan whenever you update open-source components or upgrade entire libraries to catch any newly introduced vulnerabilities. Following security advisories: React promptly to security advisories from open-source project maintainers or vulnerability databases like NVD. After code changes: If you modify open-source code, scan afterward to assess any vulnerabilities introduced by your changes. Before major deployments: Prior to deploying new versions of your software, scan to ensure no critical vulnerabilities remain unaddressed.

Automated scanning should be continuous and integrated into the SDLC, including post-deployment phases. Scheduled manual reviews, with threat modeling and more general topics like license compliance, should occur at least annually (ideally more frequently) and when new OSS components are incorporated/before major changes.

In my experience, OSS is awkward to scan for vulns. You can use Snyk or similar, but they can always miss things. You could check manually, but how do you trust trust? (read on trusting trust). Instead, define what you're ok with. Are you ok with OSS being used to update a SemVer? What about handling financial data? For environments that need higher levels of protection, consider airgapping it. Consider rolling your own. Consider choosing a company who makes OSS with a public face you can sue if it all goes wrong. It's hard to trust trust, but a one-size fits all approach is not right here. Instead, decide on your security posture and mitigate the most extreme risks

Static analysis (SAST): Checks code without running it (fast, good for basic flaws). Dynamic analysis (DAST): Scans software during execution (more thorough, can be resource-intensive). SCA tools: Map your codebase against known vulnerability databases (efficiently identifies known issues). Manual review: Deep examination by skilled developers (best for complex vulnerabilities).

Identify the device's operating system. Identify software installed on the device. Identify accounts, open ports, and other details as specified. Report on systems identified on a network. Report on any identified vulnerabilities.

A key mistake organizations make when fixing OSS vulnerabilities is blocking the release of new versions of software with known issues identified (e.g. "shall not release with high or critical vulnerabilities"). This is generally the WRONG approach, because it relies on the recency bias and causes teams to index on the most recently identified vulnerabilities. If a newly-identified vulnerability is already present in production code, then the marginal risk of releasing a new version containing the same vulnerability is zero. The key is to prevent release when: - New functionality in a product has a known vulnerability above your risk appetite. - There is a security regression in a given OSS library, which would make you less secure.

Gran parte de las correcciones pueden hallarse en foros especializados con profesionales que comparten los procedimientos necesarios de manera pública y gratuita, un ejemplo: cuando es publicado un nuevo CVE, cientos de especialistas ya comparten su trabajo. Sin embargo, esto sería solo una pequeña guía. Levantar un ambiente de pruebas o pre-producción con las modificaciones realizadas permitirán conocer si éstas no afectaron el desempeño del OSS.

Several Open source scanning softwares are available to scan for any known potential vulnerabilities. However, more than tools, its important to first control and have visibility open source components during SAST, SCA, CI/CD integration and change management. A lot of organizations do have good inventory of open source softwares that they use. And hence they do not know the threats associated with these. 3

Most OSS scanning focuses on previously-known vulnerabilities, which is certainly useful, but not entirely comprehensive. Identifying flaws in OSS not publicly reported is much trickier, but also important. These can take the form of: - Vulnerabilities accidentally introduced that merely sat undetected for years (like log4shell) - Vulnerabilities intentionally introduced by malicious actors to attack organizational software supply chains. Both of these things are extremely dangerous. Ways to reveal them include: - Static analysis of the OSS code itself - Analysis of project and contributor reputation - Hunting for key indicators of malicious software like typosquatting, etc.

In the broader context of scanning OSS for vulnerabilities, it's crucial to maintain a security-conscious culture within the organization. Encourage open discussions about security practices and ensure that all team members are aware of the importance of software security. Also, consider the ethical and legal implications of OSS usage, and ensure that OSS components are used responsibly and in accordance with their licenses.