-
-
Notifications
You must be signed in to change notification settings - Fork 666
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Review requirementes 14.2.6 and 14.2.8, potential move to V10 #2166
Comments
These are great requirements. Well done.
** Revised Oct 23: I think we should just not use risky libraries instead
|
Those are current requirements that are questioned by 2 persons... |
With a little wordsmithing, I personally like them. That's all. |
@set-reminder @tghosth in 1 day to double check the reasoning behind this split but strongly consider re-connecting them and simplifying the requirement. |
⏰ Reminder
|
By nature, these requirements are probably better put into the proposed "architecture" section for V10 (discussed in #2173) |
Ok @elarlang so my proposal:
I think this remains something worth thinking about for the most sensitive applications. |
But if is so risky and so sensitive, why not to have it as default setup for everything? |
Yea. Fair point Elar. Why not just have a requirement around "don't use risky libraries" instead? |
Just for information, 14.2.6 in v4.0.3 release was:
|
14.2.6 is just a good principle for libraries you choose to use. I suggest 10.5.2 be modified to state that we should just not use risky third party libraries at all. |
I'm a bit confused... In the issue description I stated:
Response from Jim:
|
Sorry I was too fast above. Go with my latest comment in general. Why not just have a requirement around "don't use risky libraries" instead? |
So I prefer that security is not the "Department of No", but rather the "Department of Yes, and...." or at least the "Department of Yes, but....". Hence, saying if you must do risky things, at least take precautions |
Getting a bit philosophical, but I'm from the department "everything is risky by default" and have a question - how do you decide, what is risky and what is not? |
The “yes” is to use libraries with a good security history.
|
So should we change "risky" to "perform potentially dangerous operations" or "perform security sensitive operations"? |
I think the style of old version is good. Verify that
... are sandboxed away from
so that even if a vulnerability in the library was successfully exploited, the sensitive system modules/services would not be compromised. Alternatively, the libraries should be encapsulated such that only required behavior is available to the application. |
Admittedly this is not easy to quantify, but there are some of the things I look for as a developer before using a library. |
I accept your point about risky which is why I suggested different potential wording above. Jim also makes good points about how to quantify. We could include Jim's point in section text or use "perform potentially dangerous operations" or "perform security sensitive operations" instead of "Risky". What do you think? Regarding the history of vulnerabilities, I think this is more easily quantifiable as there are clearly certain libraries which have had a long string of nasty vulnerabilities in.
I take your point, take a look at my change below.
|
I have described n+1 times my concerns on the "risky" and "history of vulnerabilities" here and before that in the #1425. I still have them and this wording does not make any sense for me, it's not reasonable limitation. The requirement got in because I did not care enough and was already annoyed of this discussion in the last issue, but this did not make it valid. |
From your perspective, you would prefer to delete this requirement? |
I think it has the point and it should be in, but close to the previous version (in v4.0.3) without unclear limiting wording such as risky and "history of vulnerabilities". For level 3 application everything should be considered as risky. |
Ok so let me have one more try, I think doing this for every library is unrealistic as it means every library being separated from every other library. @elarlang
|
Let's distance from the wording and reset to the beginning: what is the application security problem to solve or address with this requirement? |
|
Keeping in mind that it should not duplicate requirements:
|
Spin-off from #2088 / the discussion over 14.2.6 and/or 14.2.8 comes from #1425.
Current requirements:
The need for those requirements are questioned for example in comments:
For me the "main error" is, if we talk about L3 requirement, then those application can not use any "too risky" and not trustful component anyway.
By content, both are more "software architecture" requirements, not a clear configuration requirements. Most likely we need a chapter for V10 for that, something to say "Software Architecture" or "Sandboxing".
The text was updated successfully, but these errors were encountered: