Thanks for the quick reply! We're definitely interested in actively pursuing results of scans. Our main goal is to maintain a list of detectable CVE's and document their status. We want to know which CVE's are false positives, which CVE's are accepted, and how to mitigate possible risks CVE pose. Ideally we would want the listing to be part of the project somehow, which can help other users who may be alarmed by the CVE's the see when performing a scan. We also want to spend time on addressing CVE's that are critical and need to be fixed as soon as possible.
What we've done so far is scanning the master branch using the dependency-check-maven ( https://jeremylong.github.io/DependencyCheck/dependency-check-maven/) plugin to scan for CVE's. We're now trying to separate the noise from the actually important CVE's (if any) by looking at the mailing list and searching through the project's Jira. At this point we're starting to explore the projects dependencies and code to see if a listed CVE is relevant, this is where we can use some help from the community. We are unsure how to best initiate communication around a listed CVE. We could reach out to secur...@apache.org, but would prefer a shorter line of communication to prevent us from reporting false positives or otherwise irrelevant CVE's. We could proceed as follows: - We keep on working finding out which CVE's are relevant, which we want to do anyway. We do need to know if it's okay to discuss the results on the mailing list or Jira or if we can maybe do some pruning beforehand together with someone more HBase knowledge. - Add the dependency-check-maven as a build plugin so we can perform the scan manually. Suppressing false positives and accepted CVE's. We always do this in an XML configuration file which also serves as a sort of documentation for developers. -Decide on how to incorporate the CVE checks in the development process (e.g., add to a build step or configure nightly checks) - Work on fixing remaining issues, tracked in Jira Regards, Wes On Tue, Mar 7, 2023 at 2:40 PM 张铎(Duo Zhang) <palomino...@gmail.com> wrote: > Thanks for looking at security problems. > > All ASF projects follow the same way to process security problems, please > see here > > https://www.apache.org/security/ > > And on the CVEs from dependencies, usually the HBase community will fix it > ASAP. And we have also enabled dependabot on github to help us fixing > dependencies CVEs(only for master branch, although). > > The protobuf 2.5 dependency is a bit difficult, as Nick said, it will break > our compatibility guidelines if we just upgrade it or remove it, especially > that all the CPEPs for branch-2.x still depend on it, doing this will break > Phoenix and other projects which are based on HBase... > > Thanks. > > Nick Dimiduk <ndimi...@apache.org> 于2023年3月7日周二 20:08写道： > > > Hi Wes, > > > > Thanks a lot for your interest. I think that you'll find this community > is > > interested in squashing CVEs. As you can see in the description > > on HBASE-27436, doing so in a way that meets our strict > > compatibility guidelines can be technically challenging. Flagging the > > attention of specific issues for the community via a nightly build > process, > > as per HBASE-20553, seems like a decent enough idea, especially if there > > are people actively interested in pursuing the results of the scanner. My > > previous experience with OWASP specifically is that it cannot perform the > > analysis to decide if a CVE is actually exploitable, and so without > > committed human collaboration, the tool (1) generates useless noise and > (2) > > degrades the confidence of casual passers-by in the quality of the > product. > > > > All that said, I think that there are several of us around the community > > who would be interested in collaboration around addressing these types of > > issues. I'd hate for you to be doing the effort AND be forced into > > maintaining a fork. Let's get your fixes merged. > > > > How would you propose that we proceed? Do you have patches you'd like to > > see landed upstream? We can start by getting you a JIRA account if you > > don't already have one. Start by filing a request on the self-service > tool, > > https://selfserve.apache.org/jira-account.html > > > > Thanks, > > Nick > > > > On Tue, Mar 7, 2023 at 11:03 AM Wes Schuitema <w...@web-iq.com> wrote: > > > > > Hello devs, > > > > > > When doing a security audit on the software we're using we've found a > few > > > CVEs in HBase. We've been looking into the mailing list and Jira in > order > > > to see if these are known and/or accepted CVEs and have found some > > related > > > issues. > > > > > > One of the detected CVEs is mentioned in an issue as low priority in > this > > > issues: https://issues.apache.org/jira/browse/HBASE-27436 (Remove > > protobuf > > > 2 dependencies). Which looking at the priority and description seems to > > be > > > an accepted CVE. > > > > > > There are also two issues mentioning integrating CVE checking to the > > build > > > process: > > > - https://issues.apache.org/jira/browse/HBASE-20553 (Add dependency > CVE > > > checking to nightly tests) > > > - https://issues.apache.org/jira/browse/HBASE-20971 (Please add OWASP > > > Dependency Check to the core build (pom.xml) and all sub-component > > builds.) > > > Both have a high priority, but are also several years old. Is this > > > something that is still interesting for the project and worth looking > > into? > > > > > > We were able to find some messages on the mailing list mentioning > > updating > > > dependencies because of CVEs in release notes. But we've not found any > > > documentation mentioning a process of detecting and addressing CVEs. > > > > > > We want to work on addressing these CVEs in our own installation. We > want > > > to find out which CVEs are relevant, and fix any relevant CVEs. It > would > > be > > > nice if we could get these changes merged somehow so we don't have to > > > maintain our own HBase fork. Updating dependencies can also come with > > some > > > subtle problems that may be difficult to solve without some advise from > > the > > > community, is this worthwhile enough to to invest time into? > > > > > > Regards, > > > > > > Wes > > > -- > > > > > > - Winner of Dutch Innovation award within Law Enforcement > > > - Active in 26 countries > > > > > > Wes Schuitema > > > Software Engineer > > > > > > phone: > > > skype: > > > site: > > > pgp: +31 (0)50 21 11 622 > > > w...@web-iq.com > > > web-iq.com > > > 67ED A1AB 34EF CA75 1F88 F2E2 ADC0 E1DD 6905 D5EA > > > The content of this email is confidential and intended for the > recipient > > > specified in message only. It is strictly forbidden to share any part > of > > > this message with any third party, without a written consent of the > > sender. > > > If you received this message by mistake, please reply to this message > and > > > follow with its deletion, so that we can ensure such a mistake does not > > > occur in the future. > > > > > > -- - Winner of Dutch Innovation award within Law Enforcement - Active in 26 countries Wes Schuitema Software Engineer phone: skype: site: pgp: +31 (0)50 21 11 622 w...@web-iq.com web-iq.com 67ED A1AB 34EF CA75 1F88 F2E2 ADC0 E1DD 6905 D5EA The content of this email is confidential and intended for the recipient specified in message only. It is strictly forbidden to share any part of this message with any third party, without a written consent of the sender. If you received this message by mistake, please reply to this message and follow with its deletion, so that we can ensure such a mistake does not occur in the future.
