thats what you're sayin right? they can break it anyway, BUT here is what we can do. we can open the door for them ourselves like what Kaspersky were going to do, OR make it hard for them as much as possible
No, what I am saying is that anyone with a sufficient reverse-engineering skill-set can dig into how Kaspersky's local components work, but the web-based side would be more effort because one would have to breach them to access such (e.g. insider employee/s).
You can rely on static and dynamic reverse-engineering techniques to learn about how the solution works to accomplish certain things. Albeit, it could take a long time given Kaspersky is a large project (and depending on how much you're trying to find out), but it is definitely feasible if you are willing to spend the time to do it and already have a strong background in reverse-engineering.
For the U.S government, it'd be even easier, because they'll have access to a lot of resources when it comes to reverse-engineering... it wouldn't be just one noob in a room all alone doing it, it'd be a whole team potentially ranging anywhere between 40-100+ people focusing on different pieces of the software and working on conjunction with one another (e.g. if someone gets stuck and another person has experience on the aspect another is stuck on, then they can help them, and the games can continue), speeding up the whole process at an effective rate and reducing the time it might take individuals X, Y and Z of a whole year to 1-3 months with all of the resources and additional trained and experienced staff involved in the operation.
It would not be unrealistic to predict that if the U.S government wanted to do something like this, they could rely on other companies with strong backgrounds in reverse-engineering to put in some of their resources and help, making things even easier. And there's a lot of companies who collaborate with the U.S government or who get requested to assist the U.S government in things (sometimes they are not even based in the U.S) and it is why many companies recently started signing agreements with one another to vow not to help in anything cyber-attack related for a government.
Now, let's talk about what you can do when developing a product you do not want to be insecure to the U.S government.
- Follow safe programming practices to minimise the potential of exploitable vulnerabilities - even if you mess-up and make a mistake which would have traditionally been exploitable, using safe programming practices alone can completely block off that mistake from being exploitable.
- Avoid using undocumented or risky functionality which you can access over documented, popular, well-tested and reliable functionality (e.g. sometimes people think they know better and then use X, Y and Z which then suddenly gets changed out of no where and then screws up their whole product).
- Try and do things which would affect the integrity of the OS or other third-party software running on the machine as much as possible.
- Follow a proper Q&A system and make use of automated stress-testing attacks on your services (e.g. fuzzing, driver verifier, etc.).
- Get good in-house penetration testers employed or rely on reputable and skillful freelance ones to try and find problems and solve them on a consistent basis.
- Consult other professionals for improvement advice or alternate possibilities which are more secure when it comes to the underlying design of implementations (also important during the planning stage) because a bad design will ruin the entire product.
- Perform more sensitive tasks on the backend of servers instead of locally on the customers machine (and make sure those servers are secure in the sense that they are following good practices and are under good maintenance care and monitoring).
- When doing anything like transmitting data back to a web-based service (e.g. company's services) use HTTPS over HTTP (Port 443 not 80) and transmit as least as possible to prevent there from being a gold-mine of data leaks if the worst of the worst happened. It would also be a good idea to rely on encryption of the data before transmitting it via HTTPS as an extra layer of defense in-case the local machine has been subverted.
A good one would be to get them on-board with using your software if it is possible, that would make their interests of keeping it secure aligned with yours. If they see any issues, they may then tell you about it to prevent themselves from being more vulnerable. It's also not uncommon for the U.S government to be really picky and make requests for additional features (e.g. Intel have allegedly added a kill-switch at-least once in the past for a firmware feature as per requested by the U.S government).
....
In other words, just design and the develop the product in the best way you can where the whole product's security wouldn't be broken if someone from outside the company were to see how it worked inside (whether via reverse-engineering or a genuine source-code audit) or if an employee leaked something illegally, etc.