We need to kick off a dedicated security committee

[jwagantall]

The Hiero project should consider the formation of a dedicated security committee to assist on the following tasks:

• Define policy and guidelines for collaboration and process for approval on new practices
• Badging program (review pass criteria and help drive the project towards adopting new security badges)
• Define and review current credential protection management (this includes actions secret management and other CI/CD token usage)
• Review Code scans (At the moment we have Snyk running scans but there is so much more functionality needed to be addressed as well as discussion on other release and code scanning tools that can help the project stay up to date)
• Review artifact and deliverables scans (related to previous point)
• Formulate an Incident response plan
• Community outreach and education to help strengthen our best practices.

Please let me know if anyone would like to volunteer or can help with your expertise on these topics.

[popowycz]

Hi Jessica - you can count me in on this. You captured many of the core elements well. I'll build upon what you listed to help clarify (at least for me) what we would want to include as deliverables of the committee:

• Policy: Is there a good reference example that we could use in developing the scope of this.
• Badging: This ties a bit into the policy where I would like to formalize that each project have a security reporting as a baseline. I would like to see some common reporting of the state of security at a repo level. We could consider requiring having something like the OpenSSF scorecard to serve that purpose.
• Artifacts: This might be referenced within the scorecard, but I would like to suggest that tagged builds from a repo included references to relevant security reports. Additionally, I would like to see SBOMs become standardized with builds.
• Incident response plan: Following responsible disclosure practices - this makes sense on how we deal with internally identified or externally sourced vulnerabilities or contributions that address various levels of criticality.

[jwagantall]

Thank you @popowycz! It would be great to have you on board on this team!

I will work on an initial Policy (I don't believe we have one but I worked with other Security Committees before and I can leverage what I learned to build ours)

Definitely we need to leverage from OpenSSF and standardize our reporting. I would also like to see that and I will be happy to be part of this team as well to help out.

[bomanaps]

I have a question. I saw this earlier today and am interested in working on this. I’m not an expert per se, but I would love to join. Is there an Incident Response Plan in place? Although I am currently looking into Snyk, CodeQL, Trivy, and HashiCorp Vault to understand their capabilities.

[jwagantall]

Thank you @bomanaps ! We will be happy to have you in the team.
We do not have an Incident Response Plan in place. All the items I mentioned are more like a wish list and something that we can build up as a team.

Since I am going to be part of the team too, I will like to help preparing a proposal.

[jwagantall]

@bomanaps , forgot to mention in my comments, we are using Snyk at the moment. I just started looking at the reports and will work on making those available to the community.
We might also want to leverage other tools that are available in GH as well as other artifact storage like for example DockerHub (which allows artifact scanning) Depending on the location of our artifacts.
I also have some knowledge of SPDX SBOMs and SBOM managing tools so I can add this to the list too.

[bomanaps]

I am still looking into the Snyk tutorial to deeply understand how it works, and I also discovered this. I will get back to you soon with a report. https://github.com/revanite-io/pvtr-github-repo

[jwagantall]

Thank you so much for your comments!

Will let this discussion run little longer to see if we can get more volunteers.

Ideally, I would like to have someone from the tech teams or expert on SDKs to help out building the response plans and actions to take in parallel with day to day development. While I agree that all devs should be mindful and working on integrating security fixes in their code, having a security dedicated developer responsible to making sure this is happening across our repos would be nice to have.

[bomanaps]

After running Snyk on hiero-consensus-node locally, it identified 15 medium vulnerabilities in the codebase. There were 30 in total, but some were in the test code, which is not quite important for now. The general guideline is to have a CI/CD pipeline with security integration—something like
┌────────────┐ ┌────────────┐ ┌────────────────┐ ┌─────────────┐ ┌────────────┐
│ Code │────▶│ Build & │────▶│ Automated │────▶│ Security │────▶│ Deploy │
│ Commit │ │ Unit Tests │ │ Integration │ │ Scanning │ │ (if clean) │
└────────────┘ └────────────┘ │ Testing │ └─────────────┘ └────────────┘
└────────────────┘

• Looking closely at the scan results, these vulnerabilities point to fundamental security coding practices that aren't being followed consistently. The issues aren't just isolated bugs - they represent systematic patterns of insecure coding.

[jwagantall]

Thank you @bomanaps , Can you please email me at [email protected]? We have our internal free Snyk account that I can add you to also. At the moment, we are still discussing internally if we adopt an additional plan for Snyk which depending on the progress of this working group we will consider.