How do you prevent hired developers from stealing code? [closed] - security

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I'm in the process of opening up a company that will eventually hire 2-5 developers to work on a large web app.
My main concern is that one or more developers could steal the code. I could make them sign contracts against this type of thing, but I live in a country where the law is "bendable".
Is my only option to lock them up in a room without inet access and usb ports?
I'd love to know how others have solved this problem.

Don't hire people you can't trust.
Break the app into sections and only let people work on a subset of the app, never getting access to the whole thing.
Make it worth their while - you're opening a company, hire people and give them some stock options. Make sure it's more attractive for them to make you succeed than otherwise.

How about keeping them all happy and show that you appreciate their work?

You may find that you think your source code is the valuable part of your business, but you can always build that again. Your real advantage over your competitors is usually in the people you hire, and in the business relationships that you establish in the course of naturally doing business.

My suggestion is not technical but social: Make them feel good.
Most human beings have a moral base that prevents them from hurting other people who have treated them with respect and generosity.
There's a slim chance you'll wind up hiring a psychopath, in which case this approach won't work -- but then, it's likely to be the least of your worries.

The only thing that occures to me is to make them sign a contract where you explicit that if they share any code outside the project ambient, they'll compromise to pay you a large amount of money. But there's no guarantee they'll not do it anyway ..

You can create a vitual environment (a virtual machine) with limited internet connection (only to specific servers - git/svn server, database server, etc) and no copy/paste possibilities.
This virtual machine would be a standard environment with common developer tools.
At the office a developer would remotely connect to the virtual machine and start developing without being able to steal the code.
Of course he could print the screen or type the code on another computer but it's still very hard to steal.

There are many encrypting softwares available to encrypt the code. Here is an example http://www.codeeclipse.com/step1.php
In other words you can hide the code of one developer(one module) from the other developer and he will not be able to take the whole code himself in any case if you follow this approach.
Thanks
Sunny

Related

How to keep up code quality and Agile processes within a distributed team? [closed]

Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
my team is about to change into a distributed Agile team and I am concerned of how we are going to protect our code base and processes.
Currently we are an extremely Agile team dedicated to code quality and we would like to continue along this path. However, none of us has ever worked on an Agile distributed team.
Does any of you guys have some suggestions or experiences to share to help us protect Agile processes and code quality in a distributed environment?
Do you know any books I could read about it?
Thanks.
First of all, I think your text sounds a bit defensive/pessimistic ("protect the process"). Of course I understand your concerns, but be open and try to embrace the change :)
Currently I am part of a project including 23 developers from 4 different countries (but just one hour time difference). The company hired external developers as we needed more man power; We have 4 teams and additional 3 dedicated testers; the 'main' developers (who are part of the company) and Product Owners are all at one location.
We have all the standard Agile Processes/ Techniques, but of course it was challenging and we needed quite a while to figure everything out. So, I can share our experiences and tell you what worked for our environment and situation.
As the timezone was not that different we created mixed teams; 2 'main' developers and (at least) 2 from another location. This was quite important for several reasons:
Knowledge is shared much faster and helps the remote guys to understand the domain
The Scrum Master can support the remote developers if they need specific information from another person (e.g. PO)... emails are easily overlooked.
You have a better control of the source code; the main developers can organize code reviews, do pair programming sessions and/or create guidelines.
Communication is the most important thing; always include everyone for important decissions
Agile is of course about people, but when dealing with remote teams, you need tools. What worked for us:
Skype for daily standups
join.me or Teamviewer whenever you need to share your screen. It also works for remote pair programming
corkboard.me for retrospective or whenever you need a virtual corkboard
Google Docs or Google + can also be used for sprint plannings etc.
Get the people together from time to time, especially at the beginning. It helps if you saw your colleagues at least once and helps even more if you drank a beer together :) Try to create an atmosphere where each developer is treated equally, to get a real productive environment.
Unfortunately, I do not have the resources I read about that topic. But there are plenty of blog entries etc. around for distributed agile teams.
Hope it helps a little bit for your situation. If you have any other/more specific question, do not hesitate to ask :)

Protecting source code from theft during development [closed]

Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
Is there any way to protect my code during development so that if a developer leaves my company they are unable to access files in my project?
This is especially important with TFS where the project is downloaded locally, cached, and available for offline use. Ideally the code would be unreadable if they did not have a valid Active Directory user ID.
Even if this idea is not possible, I'd like to learn of any practical deterrent you can think of...
You have to extend some form of trust to your developers. If you can't trust them not to take source code with them, how can you trust them not to build back doors and the like into your systems?
Moreover, if they're going to work on code, they're going to need access to it, and if they get access to it they can almost certainly copy it. You can try to limit it, but it's you trying to outthink in advance a group of people who only need to find one mistake you made. Besides, overtly distrusting your developers isn't going to help you anyway.
Are there actual trade secrets built into your code? If so, you might want to rethink that. If not, how much harm will it do in somebody else's possession? They can't legally use it, and the developers that leave will often be able to write something similar anyway.
For this, you want legal protection, not technical.
Assuming they can read the code and compile it while they are there, there's not a lot you can do (unless you ban USB sticks, CR writers, scan all their email etc, and even then they'd find a way of defeating that).
Cover it in the employment contract, make it clear that if the code turns up there will be legal action.
(I've had this happen to me in a past life - an employee did take the code with him. We knew due to an error he made in doing it, and we sent a letter from our laywers pointing out the consequences of him revealing the code to anyone else. It seemed to work)
If you are afraid of losing a code as a whole (rather than the employee copy-paste part of it)...
With your source code management system (you have one, right ?), you can probably have some hooks so that when the user gets the code, part of it is a binary file that is dedicated to only that user and is necessary for the code to compile correctly and run correctly... if you push to the extreme, that will mean having the right hardware system (TPM, hardware keys...etc).
So after you have dealt with all the paperwork as Paul suggests for example, if ever the code leaks anywhere, you can track who is at fault (and knowing that would probably deter anybody to actually even try)
All things considered... no (especially if the project is stored locally as you mentioned). If a developer has access to source code, they have the ability to steal source code. IANAL, but to deter this sort of thing, you need a lawyer to draft up a non-disclosure agreement (NDA) and get your developers to sign it.
From Wikipedia, an NDA is:
a legal contract between at least two parties that outlines confidential material, knowledge, or information that the parties wish to share with one another for certain purposes, but wish to restrict access to by third parties. It is a contract through which the parties agree not to disclose information covered by the agreement.
This really isn't an crypto question. But there is an answer.
1)You should limit developers and only give them access to source that they need to get the job done. This the security principal of "least privilege access". Store binaries of libraries or the executeables in source control if need be.
2)Force all developers to sign a Non-Disclosure contract. Higher developers that you can sue. For instant defending this contract in India is more difficult than defending it in Indiana.
There are ways to secure your entire development environment so that so programmers can keep or take souvenirs of what they are working on. Take a look at www.chaperon-secure.net for possible solutions from secure development environment to vaulted source code repositories.
You can somewhat reduce the risk of code theft if your application is cleanly built into components/modules/plug-ins. The dev would only be given code access to the components that they work on, and compiled code for the rest of the application. I am, of-course, assuming that it's only worthwhile to steal the application as a whole and not just a handful of components.
On the other hand, you would be surprised that code itself is not always as valuable as you would like to think. If there is no sensitive IP in the code that can be directly resold, then is your dev going to just recompile and go head-to-head with you with their own application?

Do you use 30 day trial servers to do development work? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I know this is an odd question but I need to ask it to get information to present to a client. Their lead network admin wants me to work on 30 day trial servers like Sharepoint & SQL Server to develop projects for their clients. While I will do as they ask, I'm not convinced this is the best way to go about developing software or troubleshooting previously developed software. To be honest, I've never worked on custom development for any server/software using a trial version.
What arguements are there for and against working on trial software/servers?
Pro: It enables you to mock up a concept and see if it seems like the development path will be easy before you shell out large amounts of money for the real deal.
Cons: It could trap you in a vicious cycle of wiping your virtual machine and re-installing the OS, the trial version, and your product (you do use source control, correct?) if they are hoping that this will alleviate the need for ever paying for the real product.
Suggestion: If you don't mind unsolicited advice, then I would determine why the lead admin wants to use the trial versions -- and then go from there. Until you know the reasons you cannot respond to them.
If they are doing it for the pro reason, then determine if you feel comfortable working with the possibility of switching technologies 30 days into your build. (Can you do it efficiently?)
If they are doing it to avoid spending money, present some of the alternate open source / free options that you are comfortable developing with. If they will not change their modus operandi at that point, then do what is necessary, knowing what you will be walking away from / getting in to.
(And if you don't mind one more bit of unsolicited advice -- if they are doing it for the con reason and will not change WALK AWAY)
Point them at BizSpark. Microsoft is begging people to use their stuff. A hunny will get you everything on the map for 3 years or until you start making money.
Oh, to answer your question: If I need to get funding for technology not present in the infrastructure or to do a proof of concept I would not think twice about using evals. That is what they are for. I would be evaluating the suitability of the product for use with my designs. Seems easy to me. Maybe I am just, hold on, i have to give my parrot a cracker... ;-)
Apart from the ethical arguments, there are practical ones:
What are you supposed to do if development overruns? Start reinstalling everything, wasting several days doing so?
Additionally, if the client is so strapped for cash that they want to do this, how can you be certain they will pay you (either due to cash flow problems, or simply because of their shady ethics)?
I'm pretty sure that that kind of use is a violation of license terms. Trial editions of servers are for evaluating a product. And if you are in fact creating a product, then you have gone way beyond evaluation.
I would never work under such terms. If you are developing a concrete product, get proper licenses for the development tools. I know that the developer edition of SQL server is not hugely expensive (compared to a version licensed for production use), so I would imagine that the same counts for Sharepoint.
And then there is of course, as already mentioned, what do you do when the trail period expires?
I wouldn't mind doing this so long as the job is shorter than 30 days. Make sure your work contract they're paying for the time worked and not specific deliverables, because your deliverables are time-bombed.
Also be prepared to walk away. If this company doesn't have resources to get the right software, you don't want to be there longer than 30 days anyhow.
Microsoft provides several pre-built virtual machines, that contains full stacks.
(Server 2008/Sql 2008/Sharepoin) (Server 2003/Sql/Project Server) etc.
They are time bombed, but often (not always) Microsoft will provide a new image after the time out.
The benefit of using these images is that they are already configured and good to go.
As an example here is a beta of sharepoint 2010 (http://www.microsoft.com/downloads/details.aspx?FamilyID=0c51819b-3d40-435c-a103-a5481fe0a0d2&displaylang=en).
If the project has a quick timeline, it provides the developers access to the configured stack right away, with no ramp up time of building new virtual machines.
Esp when working on beta/early release software this is great.
The SQL Server evaluation's download page mentions that the evaluation license is good for 180 days, and specifically advertises it as a tool you can use for mission-critical applications. This tells me MS is fine with your using it for development work.
To answer a question with more questions:
How long does this project run?
What phase of the effort are you in now?
Is this an internal/proof-of-concept project, or something that your customer(s) will be using for a long time?
If you are going to need to use SQL Server for Operations & Maintenance support months past the initial evaluation period, you ought to get a license for the full version of it. And also consider what your customers are using so that you can reproduce any bugs that come back from them.
I don't think it's ethical to continually renew evaluation licenses to have a longer evaluation period. Companies call them "evaluations" as a try-before-you-buy, not a keep-trying-without-buying.
I'm not sure what others are seeing as unethical here. If the project is short enough to be completed within the 30 day trial, I don't see any issues. I think that's a great use of trials - if they can't handle a clients applications then they aren't a good option and you can use something else.
I think others here have given some good advice regarding the longer than 30 days projects and some good contract ideas.
How in-house do the servers have to be? Would a hosted solution work for them? (Dreamhost, Amazon Web Services, whatever)? Some hosting systems provide pretty complex machine images (lots of stuff pre-installed--definitely AWS, presumably most others), decreasing setup time/effort. I think those come with licenses, though I don't honestly know. Plus, in at least some cases, you (they) only pay for what you (they) use.
Obviously no good if the physical machine needs to be in-house, or if things are otherwise super-sensitive.

how to protect My Programs? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
Let's say I have designed s very important system, and this system costs thousands dollars. I want to protect my system with a serial number as I know crackers will try to edit the binary code to bypass the serial number.
I have read about using a checksum function and apply it over my binary code and check the value if changed, but again, we are talking about a condition a cracker can avoid by editing the code.
My question is: what's the most used technique to protect important programs?
I have yet to see a "protected" digital product that had not been cracked pretty quickly after its publication (or in some cases, before its publication). Sorry, but it's the reality. You have to get the revenue by making a good product. Most of those who want to use it and can afford, will pay.
There will be a few dickheads, but that's life. You better be kind towards the legit users of your software and not bully them with weird copy protection attempts that don't work anyway.
If your app is working offline, whatever checks you do (check sums, serial code validity, etc), do them often, repeating verification code, in many routines of your software. Obfuscate your code, to make reverse engineering a more difficult task, and, if you have the possibility, implement an online check, part of the core functionality of your app residing on your server, and being serviced only to those installations that you have checked server-side for valid license key. Associate the license key to some form of unique identifier of the hardware the app is running on, and if you check online, have statistics concerning the IPs that make the verification request: if you encounter more IPs trying to verify the same license key, contact the buyer and approve a list of IPs they usually log on from, whilst blacklisting any other until specific request from them, either by mail or by phone.
The most used technique is serial numbers. But your customers will have access to the code, so they will be able to bypass your serial number check, no matter how much work you put into obfuscating it.
However, if you can provide your software as a subscription-based or one-time-payment web application, then people will not be able to do this. Whether this is feasible or not depends on the type of application you're writing.
I would always recommend to build a custom software protection before applying any kind of commercial protector such as a Packer.
In any case just a serial validation and a checksum check are not going to keep crackers away.
I would recommend you to visit my new blog www.anti-reversing.com and take a quick look at the anti-piracy tips & tricks page just to have an idea about what I am talking about.

How to collect customer feedback? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
What's the best way to close the loop and have a desktop app "call home" with customer feedback? Right now our code will login to our SMTP server and send me some email.
The site GetSatisfaction has been an increasingly popular way to get customer feedback.
http://getsatisfaction.com/
GetSatisfaction is a community based site that builds a community around your application. Users can post questions, comments, and feedback about and application and get answers to their questions either from other members or from members of the development team themselves.
They also have an API so you can incorporate GetSatifaction into your app, and/or your site.
I've been playing with it for a couple of weeks and it is pretty cool. Kind of like stackoverflow, but for customer feedback.
Feedback from users and programmers simply is one of the most important points of development in my opinion. The whole web2.0 - beta - concept more or less is build around this concept and therefore there should be absolutely no pain involved whatsoever for the user. What does it have to do with your question? I think quite a bit. If you provide a feedback option, make it visible in your application, but don't annoy the user (like MS sometimes does with there feedback thingy on there website above all elements!!). Place it somewhere directly! visible, but discreet. What about a separate menu entry? Some leftover space in the statusbar? Put it there so it is accessible all the time. Why? People really liking your product or who are REALLY annoyed about something will probably find your feedback option in any case, but you will miss the small things. Imagine a user unsure about the value of his input "should I really write him?". This one will probably will not make the afford in searching and in the end these small things make a really outstanding product, don't they? OK, the user found your feedback form, but how should it look and what's next? Keep it simple and don't ask him dozens questions and provoke him with check- and radioboxes. Give him two input fields, one for a title and one for a long description. Not more and not less. Maybe a small text shortly giving him some info what might be useful (OS, program version etc., maybe his email), but leave all this up to him. How to get the message to you and how to show the user that his input counts? In most cases this is simple. Like levand suggested use http and post the comment on a private area on your site and provide a link to his input. After revisiting his input, make it public and accessible for all (if possible). There he can see your response and that you really care etc.. Why not use the mail approach? What about a firewall preventing him to access your site? Duo to spam in quite some modern routers these ports are by default closed and you certainly will not get any response from workers in bigger companies, however port 80 or 443 is often open... (maybe you should check, if the current browser have a proxy installed and use this one..). Although I haven't used GetSatisfaction yet, I somewhat disagree with Nick Hadded, because you don't want third parties to have access to possible private and confidential data. Additionally you want "one face to the customer" and don't want to open up your customers base to someone else. There is SOO much more to tell, but I don't want to get banned for tattling .. haha! THX for caring about the user! :)
You might be interested in UseResponse, open-source (yet not free) hosted customer feedback / idea gathering solution that will be released in December, 2001.
It should run on majority of PHP hosting environments (including shared ones) and according to it's authors it's absorbed only the best features of it's competitors (mentioned in other answers) while will have little-to-none flaws of these.
You could also have the application send a POST http request directly to a URL on your server.
What my friend we are forgetting here is that, does having a mere form on your website enough to convince the users how much effort a Company puts in to act on that precious feedback.
A users' note to a company is a true image about the product or service that they offer. In Web 2.0 culture, people feel proud of being part of continuous development strategy always preached by almost all companies nowadays.
A community engagement platform is the need of the hour & an entry point on ur website that gains enuf traction from visitors to start talking what they feel will leave no stone unturned in getting those precious feedback. Thats where products like GetSatisfaction, UserRules or Zendesk comes in.
A company's active community that involves unimagined ideas, unresolved issues and ofcourse testimonials conveys the better development strategy of the product or service they offer.
Personally, I would also POST the information. However, I would send it to a PHP script that would then insert it into a mySQL database. This way, your data can be pre-sorted and pre-categorized for analysis later. It also gives you the potential to track multiple entries by single users.
There's quite a few options. This site makes the following suggestions
http://www.suggestionbox.com/
http://www.kampyle.com/
http://getsatisfaction.com/
http://www.feedbackify.com/
http://uservoice.com/
http://userecho.com/
http://www.opinionlab.com/content/
http://ideascale.com/
http://sparkbin.net/
http://www.gri.pe/
http://www.dialogcentral.com/
http://websitechat.net/en/
http://www.anymeeting.com/
http://www.facebook.com/
I would recommend just using pre built systems. Saves you the hassle.
Get an Insight is good: http://getaninsight.com/

Resources