I believe most of the critical/high vulnerabilities are a result of outdated dependencies.
Another thing to consider is that to participate as an active developer on Ironbank the user must have a DoD CAC which allows them access to the Ironbank repository and the vulnerabilities. I'm not sure if anyone here has one but I do. I was able to get the process started with the 3.6.1 version and there are a number of critical and highs. Some of the examples are: Apache Shiro before 1.5.3, when using Apache Shiro with Spring dynamic controllers, a specially crafted request may cause an authentication bypass. Neo4j through 3.4.18 (with the shell server enabled) exposes an RMI service that arbitrarily deserializes Java objects, e.g., through setSessionVariable. An attacker can abuse this for remote code execution because there are dependencies with exploitable gadget chains. HttpObjectDecoder.java in Netty before 4.1.44 allows a Content-Length header to be accompanied by a second Content-Length header, or by a Transfer-Encoding header. Looks like the Apache Shiro library is one of the problem spots. I do agree with your assessment that including a scanner in the normal build process would help a lot. Jim On Tue, Dec 20, 2022 at 3:08 AM Florian Hockmann <[email protected]> wrote: > It would be good to know what kind of vulnerabilities Ironbank can find. > Most of such scanners I know simply use a database of known vulnerabilities > that include the libraries and their versions that are affected. The > Log4Shell vulnerability from last year is a good example that could be > found by such a scanner. > > In general I think that we should ideally try to include such a scanner > into our usual dev process so we can find those vulnerabilities early and > then fix them. Fixing them will probably most of the time just mean > updating a dependency. > If we just add Ironbank as an additional release channel behind our usual > release process, then we just get notified about vulnerabilities after we > just have released a version with these vulnerabilities. I think that would > only lead to additional pain for us as we would have to fix them and then > start another release process to perform a release without the > vulnerability. > > GitHub already offers such a vulnerability scanner that works together > with Dependabot. This means that Dependabot will create a PR to update a > dependency if that contains a known vulnerability. These security related > PRs will be marked as such, but in a way that is only visible to > maintainers of the repo. So, we can prioritize these security related PRs > over the usual Dependabot PRs that sometimes overwhelm us due to the high > number of dependencies we have. > This improves the security of TinkerPop in general and I think that it > also improves our dev process as we currently get tickets for such security > problems manually created by users who probably already execute such > scanners on our JARs / Docker images (two recent examples: > TINKERPOP-2843[1] and TINKERPOP-2826[2]) and then they are usually also > addressed by someone who manually updates the dependency. > If the Ironbank scanner works in a similar way, then this would also make > it a lot easier to publish our images to the Ironbank registry as that > should ideally not uncover any new vulnerabilities since they have already > been found and fixed by our own process (like GitHub security scanning + > Dependabot). > > By the way, I think this is the documentation of Ironbank: > https://p1.dso.mil/products/iron-bank > And here is a list of available Docker images: https://repo1.dso.mil/dsop > Unfortunately, the repos seem to be private so we can't see much, but the > list at least gives an idea of what kind of projects are already available > there. > > [1]: https://issues.apache.org/jira/browse/TINKERPOP-2843 > [2]: https://issues.apache.org/jira/browse/TINKERPOP-2826 > > -----Ursprüngliche Nachricht----- > Von: Jim Foscue <[email protected]> > Gesendet: Montag, 19. Dezember 2022 17:10 > An: [email protected] > Betreff: Re: [DISCUSS] > > Yes, Ironbank is an approved DoD dockerhub. There is no requirement for > the releases on Ironbank to be in sync with the releases in > Apache/Tinkerpop. The major requirement for Ironbank is for there not to > be any critical/high vulnerabilities in the docker image. If there are > vulnerabilities that "pop" up they should be addressed quickly. > > My team can help with that process but it would be hard for us to fix the > vulnerabilities without knowing the code. > > Jim > > On Mon, Dec 19, 2022 at 5:36 AM Stephen Mallette <[email protected]> > wrote: > > > Hi Jim, thanks for bringing this discussion here. > > > > Generally speaking, it sounds like a reasonable idea to open TinkerPop > > opportunities to the DoD environment. Would it be fair to call > > IronBank a DoD approved DockerHub? Would the idea be that TinkerPop > > would release to IronBank in the same cadence as is done with the > > standard release schedule that publishes to DockerHub? > > > > If so, I think a concern would be that supporting IronBank creates a > > hurdle to releasing that may be high and thus delay releases that > > might otherwise be acceptable outside of that space. I don't know if > > it makes sense, but perhaps releasing to IronBank should be decoupled > from standard releases? > > Like 3.5.5 would go out the door and then a separate process would go > > under way to harden 3.5.5 to meet IronBank needs? Of course, then the > > 3.5.5 in IronBank isn't necessarily the 3.5.5 in DockerHub so that > > could be problematic. Do you happen to know how other major open > > source projects do this? > > > > > > > > > > > > On Wed, Dec 14, 2022 at 4:51 PM Jim Foscue > > <[email protected]> > > wrote: > > > > > Ironbank discussion > > > > > > I would like to suggest making tinkerpop/gremlin available on the > > > DoD Ironbank docker registry (https://ironbank.dso.mil). > > > > > > Ironbank is a DoD docker registry that maintains publicly available > > docker > > > container images that have been "hardened' and given the ok to use > > > on DoD contracts. The process of hardening an image involves > > > running the docker container image through a vulnerability scanning > > > process. Any critical > > and > > > high vulnerabilities have to be addressed before getting the docker > > > container image approved for DoD use. > > > > > > My team has been using the publicly available tinkerpop/graph on a > > > DoD contract that is a prototype. But to continue using it in a > > > more > > official > > > process we have to have it approved by Ironbank. > > > > > > Therefore, I am trying to get the tinkerpop developer community to > > > get onboard to push this to Ironbank so that we and other DoD > > > contracts can > > use > > > it. > > > > > > We have access to the Ironbank system (which requires a US > > > government > > CAC) > > > and are willing to help guide the process. > > > > > > Please consider this request and provide any feedback to me at your > > > convience. > > > > > > Regards, > > > > > > Jim Foscue > > > JDM Solutions > > > > > > > > > > > > -- > > > *Jim Foscue*, Software Engineer > > > *JDM Solutions* > > > 256.694.9387 > > > [email protected] <[email protected]> > > > > > > -- > > > *This e-mail and any attachements are for the intended recipient(s) > > > only and may contain information proprietary or private to JDM > Solutions, LLC. > > > If you are not the intended recipient **please delete without > > > copying and kindly advise the sender by e-mail of the mistake in > > > delivery. This > > email > > > may be personal in communication from the sender and as such does > > > not represent the views of the company.* > > > > > > > -- > *This e-mail and any attachements are for the intended recipient(s) only > and may contain information proprietary or private to JDM Solutions, LLC. > If you are not the intended recipient **please delete without copying and > kindly advise the sender by e-mail of the mistake in delivery. This email > may be personal in communication from the sender and as such does not > represent the views of the company.* > > -- *This e-mail and any attachements are for the intended recipient(s) only and may contain information proprietary or private to JDM Solutions, LLC. If you are not the intended recipient **please delete without copying and kindly advise the sender by e-mail of the mistake in delivery. This email may be personal in communication from the sender and as such does not represent the views of the company.*
