Security

[NoureenS]

In the use of Open Source guide, there doesn't seem to be a mention of security risk responsibilities.

In using any open source software, user must be aware of any security vulnerabilities related to the code. Some considerations to validate:

• Check for public vulnerabilities - ensure the open components do not contain publicly-known vulnerabilities, such as those with reported CVEs or with vulnerabilities described in other public resources
• If possible/available, use commercial security intelligence - use additional vulnerability data sources (such as from data vendors) to augment the public vulnerability data
• Perform static analysis - use station analysis tools to validate that the open source components do not contain unreported security vulnerabilities. Report any newly-identified vulnerabilities to the open source project's author so it can be remediated.
• Perform comprehensive security reviews - in addition to the prior points, perform a comprehensive security review of the open source component

All organizations that use open source should have a strategy for responding when new vulnerabilities are disclosed. This often takes the form of monitoring the National Vulnerability Database for new information, or using tools built into a package manager (such as NPM Audit). While these certainly provide value, there are a few reasons why organizations shouldn't stop here:

There is no requirement for an open source project to report vulnerabilities up centrally. Details may exist in a GitHub issue, change log, or commit message, but would not be easily discoverable.
The vulnerability may have been found by an attacker, or a security researcher that is unwilling to publicly disclose the issue.
The project author fixing a bug may be unaware that it's actually a vulnerability, and so has no reason to report it.

A comprehensive security audit of an open source component can provide the highest level of assurance that the component is highly secure. Such an audit should include multiple areas, including:
Project Health. Is the component still maintained? Does it have a history of security vulnerabilities? Does the author release security fixes in a timely manner?
Public Vulnerabilities. Are there publicly-known vulnerabilities, either explicitly (for example, CVEs) or discoverable in the project’s issues list?
Static Analysis. Run high-quality static analysis tools to identify potential security vulnerabilities.
Dynamic Analysis. For certain types of components, perform active testing (such as web-based “black-box” testing, fuzzing.)
Secure Configuration. Understand whether there are security-sensitive configuration settings that should be enabled when using the component.
Code Review. Use the static analysis results to perform a directed code review, looking for security vulnerabilities. If any are found, build additional static analysis rules to catch the vulnerability next time.
Once this work is complete, document the findings for other teams in your organization to leverage. If any new security vulnerabilities were found, work with your security response team to inform the open source authors and if possible, suggest a fix.

[LaurentGoderre]

I think the tools we are using today really help in accomplishing this. By dockerizing our applications using official images we get the benefits of security scans for the underlying platform and automatic updates. Plus the concept of using micro-services containers using lightweight Linux distributions helps reduce the potential vulnerability.

In addition, using a standard package manager allows GitHub to report on potential vulnerabilities in the dependencies in use.

Using these standard approach will help us better manage risk.

[NoureenS]

If you are using released official images true but there may be other open source projects or components being using within a container that are not automatically updated. You may want to also have tools that notify you when the version you are using has a reported vulnerability and as best practice try to use the latest version of components, when possible, to help guard against any vulnerabilities that didn't get publicly reported, etc. Using dockerized apps alone doesn't guard against all security vulnerabilities.

[CalvinRodo]

I think you make some very good points, however; I'm not sure your suggestion is a very realistic approach to this problem.

For instance the Algorithmic Impact Assessment Tool that I built with TBS using NodeJS https://github.com/canada-ca/aia-eia-js currently has 1389 packages that it uses if we were to do a comprehensive audit on those I would have never been able to do any work on it.

Even if we were to do it on the 39 explicitly referenced dependencies in my package.json it would still prevent me from doing any work due to the burden of comprehensively reviewing each of those libraries.

I think a more pragmatic approach needs to be taken if we seriously want to be able to use Open Source libraries/frameworks.

However we can put somethings in place that would help with this.

For instance CDS has created a GitHub Application called Dependency Checker
https://github.com/cds-snc/dependency-checker which will give you a "trustworthiness" score when integrating dependencies into your project.

Having an eco-system of tools that perform scanning and other automated tests against your code as part of a build pipeline is in my opinion a much more realistic and achievable goal then having to manually validate every dependency.

Not saying we can't manually vet libraries I just don't think the lack of it should become a blocker in opening up our code.

[obrien-j]

@NoureenS : I agree with everything you've said, as long as you replace 'open source' with 'software'. :)

"All organizations that use open source software, should have a strategy for responding when new vulnerabilities are disclosed. "

[NoureenS]

True 😊. OSS development should follow any regular software development lifecycle practices there are already! Sent from Mail for Windows 10 From: obrien-j Sent: Monday, April 1, 2019 9:54 AM To: canada-ca/open-source-logiciel-libre Cc: NoureenS; Mention Subject: Re: [canada-ca/open-source-logiciel-libre] Security (#51) @NoureenS : I agree with everything you've said, as long as you replace 'open source' with 'software'. :) "All organizations that use open source software, should have a strategy for responding when new vulnerabilities are disclosed. " — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[gcharest]

Related to #53

I'm trying to find the right balance on Security between OSS and just software dev in general. Might need to tie in with @ptd-tbs work in Cyber?

[keithdouglas]

We're working on a new process here to hopefully streamline and yet also improve our stance (by pipelining in various ways). The hard part is setting magic thresholds for some of the tools. For example, X-Ray will be required here, but we have to decide where the three categories are:

1. Go ahead, fine.
2. Stop - dangerous
3. And the hard one, in the middle of the other two: warning, caution - where the security assessor on the project will have to look at the emergent effects of the warnings from this and SCA, etc. as well. Not to mention over time.

Agile Application Security (O'Reilly) suggests 15-25% time on security activities at every timescale; we'll be trying 20% to start. SAMM from OWASP might be able to, long term, tune that number and also focus more, but we have yet to do that.

[gcharest]

We probably need to scale and automate parts of this as well. X-Ray and other such tools offer levels of governance that might be useful to all departments simultaneously.

[keithdouglas]

@gcharest, if the security stance is similar, then in principle common settings are applicable. But security assessment is needed to do this. This is where the new Agile approaches are needed (so the assessment is understood to that point up front) and we (for one) have started on.