Security Concerns Raised During Ceedling Evaluation

[arungo1]

Hello,

We recently evaluated Ceedling for embedded unit testing and found it to be a great tool overall. However, during the security approval process at our organization, we encountered some concerns that we wanted to raise for your attention.

You can view the detailed report of the findings here: Security Report.

Could you please review this and let us know if it is possible to address the issues found in the report? Additionally, we could not locate a security.md file in your repository (see: Ceedling Security). Could you provide guidance on how security issues are handled and reported for this project?

We are eagerly waiting for your response and any actions that can be taken to resolve this matter.

Thank you!

[Letme]

Hello,
Can you explain more about what the findings in Security Report mean? There is no cryptography in Ceedling, the command used is just installing a gem (not even running a ceedling itself) , so I think you tested how secure installing gem from rubygems.org is.

Missing Security.md should be fixed, and for that I suggest we follow the path of filling out https://www.bestpractices.dev/en (maintainer of repo can do that - it is quite some paperwork)

[arungo1]

There are some important issues.

In ruby, ceedling installtion directory .gem\specs\rubygems.org%443\specs.4.8 file having below crypto wallet related strings

and installation directory having .out file which consider as executable

[Letme]

That is package specs 4.8.12, I assume it is a Ceedling dependency. But even if they are strings related to crypto-wallets, what does that mean? That specs 4.8.12 transfers money to those wallets, or are those wallets just there because developers wanted a donation which will be untaxed?

Can you maybe rather check the latest release? There, gem is a bit more cleaned up and maybe it does not have .out file anymore (although I would assume those are from examples).

[mkarlesky]

@arungo1 Thank you for this report. This is well outside what I was expecting when opening this issue!

I can explain to you what I believe you are seeing. What to do next is a difficult question.

Ceedling is built with Ruby. Ruby includes the idea of Gems for distributable packages. A Gem may depend on other Gems to provide its functions. Ceedling does depend on a handful of other Gems. Gems themselves require a catalog. The specs.4.8.gz file is a tailored version of the entire Gem registry that helps the local Gem installer do its work. The items the security scanner highlighted are all Gems in that index. Ceedling itself does not depend on these nor use them. I suspect there is nothing nefarious going on here and that those registry listings are merely providing version information for Ruby Gems — that Ceedling does not use — that are directly or indirectly involved with cryptocurrency applications.

We're not in a position to directly address this concern. It may be all but practically impossible to use a different registry that omits these references that triggered the security scan. Perhaps some day, when time allows, we can look into this, but there are many more higher priority issues to work on at the moment.

If your organization's policy is to simply not use anything that triggers this security scan, I'm afraid there's not a lot we can do to help at the moment. To my uninformed eye, this scan seems to be rather brute force and conservative. It saw the names of packages that can be used nefariously and flagged Ceedling as high risk. If you have a mechanism to investigate these concerns and resolve and document them through manual validation, that may be the only workable option here.

We certainly do not want security concerns to limit the adoption of Ceedling. We have already taken care in the newly updated Docker images to address previous security concerns there. This particular security concerns seems difficult to address with limited resources. If you can tell us more about your organization's policies or what you learn in relation to the Gem registry here, we would love to know those things towards ensuring compliance and security as work continues on.

[arungo1]

Thank you for your perspective on the matter.

Our IT security team is currently reviewing the tool further, and they are specifically looking for a formal security policy, such as a SECURITY.md file. Do you have any plans to update this, or is there a draft version available that we could share with us? Having this would be highly convenient for our IT security team's assessment.

[mkarlesky]

@arungo1 We do not currently have that file, but we are aware of its use in Github projects. It seems entirely appropriate to include it in the upcoming 1.0.0 official release. As your organization is clearly more experienced with this, we would be happy to follow your IT department's lead on content and format here. If you can provide draft language, an approved example, or other details, we will happily incorporate it.