3

We are delivering an application which our customers can use on their network cluster. Now, is there any way that we can certify that the software is malware proof and is not going to spread malware on their network? That caused me to think:

  1. Executables sitting on a shared file server where only handful of the users can have access to it should be, in theory, "Safe". But how do we put an objective certificate to that statement?
  2. Also, we can scan our files and may make sure the files are OK. However, how do we convey this fact to our customers in a categorical manner?
  • You could engage an independent third party (e.g., a reputable software security consulting firm) to perform a security analysis of the software. – hft Jul 20 '18 at 18:40
  • Same goes for your "scanning" process. Have your development process reviewed by a reputable third party. – hft Jul 20 '18 at 18:42
  • Or rather, probably better that your customer engage the third party rather than you, that way they feel better about it and they pay for it... – hft Jul 20 '18 at 18:43
  • 1
    OP, "executables on a shared server with some users that have access" are NOT "theoretically safe". There are very few things that are safe/secure in theory, all other things can be breached. And some random scan (virus scan?) is not evidence that everything is alright. Not even close. – deviantfan Jul 20 '18 at 18:46
5

Reproducible builds!

From https://reproducible-builds.org/

Reproducible builds are a set of software development practices that create an independently-verifiable path from source code to the binary code used by computers.

This technique allows you to prove to your customer that the binary was created from the same source code you are claiming it was created with. It can assure them that it has not been infected, tampered with, modified, etc. As long as the source code itself is not malicious, they can be sure that the binary is not malicious either. This has a few caveats, however:

  • The source code must be available, at least to your customer.

  • The customer must know how to read the source code or give it to someone who can.

Naturally, if they are unable to at least understand the source code or are not in contact with someone who can (even if that "someone" is a whole community), then this will at most provide a feeling of comfort without really improving security. Beyond this, there is no practical way to prove that your software is not malicious and does not contain malware.

  • 1
    In case of sensitive intellectual property, you can also hold the source code in escrow with an agreed third party (e.g. a law firm with a fiduciary confidentiality agreement), to be used to settle any dispute if something bad happens in the future. – John Wu Jul 20 '18 at 22:58
5

Two parts to this question:

  1. How do I show there isn't any malware in the product I'm selling?

Have a trusted third party scan, test, and verify that there is no malware. along with a good protocol for product transfer with a chain of custody will confirm. I used to work in this field and there are multiple penetration testing and scanning companies out there.

  1. How do I show that my application cannot be infected by malware (malware proof)?

This question can go down a rabbit hole. I would never tell someone that your application is malware-proof unless it only broadcasts out, has read-only filesystem, and is locked inside a safe with every hardware level I/O disabled and covered in epoxy.

If this isn't the case, I believe you can list the protections you have that make your device "malware resistant". Is there firmware scanning (checks for changes against a signature)? Is there antivirus installed? Does it have application whitelisting, etc. That, plus the 3rd party verification above should be a fair answer to your customer.

1
  1. Executables sitting on a shared file server where only handful of the users can have access to it should be, in theory, "Safe". But how do we put an objective certificate to that statement?

In addition to the other answer that mentions scanning and pen testing the existing code, I would also recommend having an independent third party look at the software/system architecture for flaws. Pen testing is good for finding bugs, but having a knowledgeable person/team look at the actual architecture/design/implementation is better for finding flaws. This point of view is expounded in McGraw's textbook "Software Security: Building Security In."

  1. Also, we can scan our files and may make sure the files are OK. However, how do we convey this fact to our customers in a categorical manner?

Not clear what you mean by "scan." Do you mean that you have a software security tool like findSecBugs or Coverity (etc) that scans each iteration of the source code to statically analyze the source code for security issues? Or do you mean that you scan for viruses in binaries or third party libraries? Or you run something like the the npm security tool to check your libraries against known vulnerabilities? If this is not clear to me it will probably also not be clear to your customer.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.