Key Points

1. GO - no VM, compiled, no classes
2. Fast execution relatively
3. Frameworks ??

References

Key Concepts

Potential Value Opportunities

Potential Challenges

Vulnerability scans of Golang code

Nancy for golang scans is open-source

https://jcdan3.medium.com/scanning-go-dependencies-for-vulnerabilities-b82db3d56b27

In this post, we will explore a solution to lower the risk of having such vulnerabilities in our third-party Golang libraries. The solution is called nancy and is free and open source.

git clone https://github.com/sonatype-nexus-community/nancy.git
cd nancy
go get ./...
go build -o nancy .

output >>

IF a vulnerability found

Chances are, it was fixed and you can simply update the module with a go get.

If it was not, consider the following:

• Using a different package that suits your need
• Reaching to the developer
• Fork the repo and fix it yourself!

Go vulnerability scanning tool

https://betterprogramming.pub/secure-your-go-code-with-vulnerability-check-tool-bb9f8c5ecd00

 the security scanning tool Go Vulnerability Check was introduced in September 2022

install tool

go install golang.org/x/vuln/cmd/govulncheck@latest

govulncheck

-test flag govulncheck -test pkg/test/*

Vuln Command-line Tool
Reading the command-line tool code usually starts from where the command line is defined. The whole process is simple, and only 5 steps to check the source.

Read and configure database client
Load config
Read the source code and sequence
Detect
Process the results

limitations of vulnerability tool

It is only aExpeirmental tool.
It only supports binary code checks from Go 1.18 and above.
It only detects vulnerabilities in the current Go version. For example, if I upgrade my Go to the latest 1.19, then the dependencies’ vulnerabilities in 1.18 will not be reported.
Its output method is limited. JSON output is too complicated, and text is only for the local environment, such as the summary output format in the source code only supports the development and testing environment.
It returns false positive or inaccurate stack reports when scanning interfaces and function pointers.

Go lang crypto package not FIPS 140-2 certified for Government work

Details on GO crypto FIPS compliance issues here

Hi Dave

2> Use of Go lang crypto libraries not validated by NIST

I see that Fabric is or will be relying on the Go crypto package. Turns out the Go crypto package is not FIPS 140.2 certified. As a result, Fabric can't ( in theory ) be used for any Federal or Canadian government solutions.

This study identified the issue on Fabric crypto libraries

Blockchain Compliance with Federal Cryptographic Information Processing Standards by James P. Howard, II, Maria E. Vachino :: SSRN

Blockchain Compliance with Federal Cryptographic Information Processing ... Under current Federal Information Security Management Act of 2002 (FISMA) requirements, all new Federal informat...

The package Go crypto is "derived" from was validated:
2017 version of BoringCrypto
https://csrc.nist.gov/projects/cryptographic-module-validation-program/Certificate/2964

I followed up with the Go security team and they provided this detail below - so far no commitment to have their crypto libraries validated.

Here's their only info on the crypto package
From Filippo Valsorda at Google, if anyone else is interested:
" Go 1.14 and earlier ship a module built according to the instructions in certificate 2964, which maps to BoringSSL tag fips-20170615. https://github.com/golang/go/blob/dev.boringcrypto.go1.14/src/crypto/internal/boring/build/build.sh Go 1.15 and later will hopefully ship a module built according to the instructions in certificate 3318, which maps to BoringSSL tag fips-20180730. https://github.com/golang/go/commit/6c64b188a53afec79563cf4ad3c5bc373036d3ae"

FIPS 140.2 requirements for crypto modules
https://csrc.nist.gov/projects/cryptographic-module-validation-program
Use of Unvalidated Cryptographic Modules by Federal Agencies and Departments

FIPS 140-2 precludes the use of unvalidated cryptography for the cryptographic protection of sensitive or valuable data within Federal systems. Unvalidated cryptography is viewed by NIST as providing no protection to the information or data—in effect the data would be considered unprotected plaintext. If the agency specifies that the information or data be cryptographically protected, then FIPS 140-2 is applicable. In essence, if cryptography is required, then it must be validated.

Many companies who would use Fabric on public projects are impacted by this regulation and the Go crypto module certification status.

Your thoughts on both are appreciated,

Thanks !

Jim Mason

Candidate Solutions

Step-by-step guide for Example

sample code block

Recommended Next Steps

Related articles