NVSHAS-9791: read runtime dependency not dev dependency #1960
Conversation
Signed-off-by: pohanhuangtw <pohan.huang@suse.com>
|
Hi @jayhuang-suse , However, when I inspect the .deps.json files using grep, I notice a pattern like this: ./<hash>/usr/share/dotnet/shared/Microsoft.AspNetCore.App/8.0.11/Microsoft.AspNetCore.App.deps.json
./<hash>/app/Swimlane.SecurityIntelligence.deps.json
./<hash>/usr/share/dotnet/shared/Microsoft.NETCore.App/8.0.11/Microsoft.NETCore.App.deps.json
Based on this, I assume the files under usr/share/dotnet/shared/ are runtime framework dependencies provided by the .NET runtime, while the one under /app/ is specific to the application and includes both runtime and compile-time dependencies. |
|
Hi @jayhuang-suse, TL;DR: Here are some "Microsoft.AspNetCore.Authentication.OpenIdConnect/7.0.0": {
"dependencies": {
"Microsoft.IdentityModel.Protocols.OpenIdConnect": "6.15.1"
},
"runtime": {
"lib/net7.0/Microsoft.AspNetCore.Authentication.OpenIdConnect.dll": {
"assemblyVersion": "7.0.0.0",
"fileVersion": "7.0.22.51819"
}
}
},
"Microsoft.AspNetCore.Http/2.2.2": {
"dependencies": {
"Microsoft.AspNetCore.Http.Abstractions": "2.2.0",
"Microsoft.AspNetCore.WebUtilities": "2.2.0",
"Microsoft.Extensions.ObjectPool": "2.2.0",
"Microsoft.Extensions.Options": "8.0.2",
"Microsoft.Net.Http.Headers": "2.2.0"
}
},
"Microsoft.AspNetCore.Http.Abstractions/2.2.0": {
"dependencies": {
"Microsoft.AspNetCore.Http.Features": "2.2.0",
"System.Text.Encodings.Web": "4.5.0"
}
}Currently, we’re including all dependencies by default, regardless of whether they’re actually used at runtime. Let me know if you foresee any concerns with this approach. cc: @holyspectral |
f8595d2 to
e2ec028
Compare
Signed-off-by: pohanhuangtw <pohan.huang@suse.com>
|
The test scanner image will manually be tested against nightly tests. Let hear the feedbacks of the results. It is about the dotNet packages and expect some dropped cases and please give an example why those missing CVEs are false-positive cases. |
|
Hi @jayhuang-suse , @holyspectral |
… if SCAN_DOTNET_RUNTIME is set Signed-off-by: pohanhuangtw <pohan.huang@suse.com>
|
I understand this package shared by enforcer and scanner but I am not sure that our code standard can accept taking any environment variable in a normal function call. @holyspectral "os.Getenv("SCAN_DOTNET_RUNTIME")" |
|
@jayhuang-suse sorry I don't really get what you mean. Can you elaborate more? |
|
Do we allow use the "os.Getenv()" in a normal function call? We usually use the "monitor" app to parse the ENV, then carry them down with the parameter flags into "main()". This PR will use this ENV directly to control the detection in a not-main() entry.... Do you have any code-standard or security concerns? |
|
@jayhuang-suse that's a good question. In terms of security, an environment variable is actually better than a command line parameter because you need extra permission to access its environment variables. That's why generally command line parameters should be avoided. Having said that, for an on/off switch I think both are acceptable. I don't think NeuVector has a strict guideline about which to use at the moment. It's worth noting that helm charts doesn't support overriding command line parameters, so it's fine with me if we want to use an environment variable instead, especially for a non user-facing configuration. |
Summary
runtimesection into our logic would make this more accurate.os.Getenv("SCAN_DOTNET_RUNTIME")to ensure backward compatibleHere are some
.deps.jsonsnippets for context: