Assuming the evaluation was security-only, and not just an acceptance scan (that is, they do not accept Ruby because they don't want to support Ruby) then:
Security analysis tools typically have a bad time with dynamic behaviors.
Run any .NET project written with modern features like ASP.NET MVC and Entity Framework through something like Veracode and see what kind of laundry list of false positives you receive in your report.
Veracode even lists many basic techniques within .NET 4 core libraries as "unsupported frameworks" as unsupported or beta only even though most of them are several years old at this point.
If you are dealing with an entity that has a strong reliance on such a tool they are almost forced to consider those insecure if they do not have the technical expertise, and the resources, to manually evaluate a project and see if it is properly written and secure.
In civilian operations where computer systems generally don't control anything dangerous or terribly expensive the mitigation is that you discuss the false positives and they are generally accepted as such in bulk.
In banking operations you still have a chance of a false positive mitigation, but you are going to spend a lot more time discussing the minutiae of each item. This rapidly becomes cost prohibitive and you start using more traditional methods.
In the military, aviation, heavy industry and the like, systems can control things that have terrible failure modes those systems so they may have very strict rules about languages, compilers, etc.
Organizations also generally write their security policy for the worst case they know of, so even if you are writing something trivial, if you are writing it for an organization that has non-trivial systems, the default is generally going to be to hold it to a higher standard unless someone requests a specific exception.