Photo Credit: JustABoy via Compfight cc
Modern technologies allow a single person to write an application code and publish it on the Web so it will be accessible by millions of users worldwide. Most people know those tools very well: Amazon Web Services, Google Cloud Platform, just to name a few. But technological revolution is not limited just to geeks’ world. The publishing industry went through dramatic changes during recent years, and as a result, a single person is now able to write the manuscript and put it in print – meaning real print like paperback or even hardcover and not just PDF or Kindle. CreateSpace and Lulu are just two examples of such self-publishing platforms.
In both cases, the final result looks like a professional product, at least at first glance. Detailed examination, however, will show a big difference in quality between a self-published and traditionally produced book. I am not against self-publishing at all. In fact, I published my first booklets using Kindle Direct Publishing, and I am still very proud of it. The question is what you are trying to achieve. If you are looking for fast results, and you are an extremely self-disciplined person, familiar with the process of professional publishing, self-publishing might work for you as it works for some best-selling authors. But if you are looking for 100% quality assurance as well as even wider and appreciative audience, professional publication most definitely will provide better results.
“Writing is a solitary occupation, while publication is a group exercise.” – Madeleine Robins
A whole team of experts, including a copy editor, content editor, technical editor, production editor, proofreaders, layout editor, cover designer, sales and marketing will make sure your book eventually looks, reads and sells much better than a self-made amateur creation. Those professionals, besides just doing their job, will communicate with you. They will scrutinize and polish your manuscript, word by word, line by line, paragraph by paragraph, and find and fix tons of misspellings and inaccuracies. You will check their work as well, and accept or sometimes reject their changes, to make sure they did not distort the original content.
Such level of scrutiny is almost impossible to achieve by self-publishing, when an author interacts just with computer programs. In addition, a professional publisher will open the door to an even wider audience and additional markets by using their “tricks” that are not available to self-publishing authors – for example, book translation contracts.
The pitfalls of self-deployment of application code might seem similar to those of book self-publishing (bugs and forgotten open ports in lieu of misspellings and inaccuracies), but the implications are even worse because the application security is at stake. In fact, various aspects of security are at stake.
First of all, confidentiality. When developers deploy their own code, it is never tested for security vulnerabilities. Even if there is a well-established testing process in place, developers, if they have free access to production environment, will always try to find a way to install a patch or change the configuration without testing. And this line of code or open port will make a hacker’s day.
There is another important confidentiality which is often overlooked: insider threat. If a single person has ultimate access to the entire process, from writing the source code to modifying the production environment, such a person essentially has the keys to the kingdom. She or he can implement virtually any backdoor, without fear of ever being caught. In a proper operational setup, where developers can modify the source code but cannot deploy it, and DevOps, on the other hand, can modify the production servers but cannot change the application code, creating backdoors becomes much more difficult task which requires collusion between two or more people. Such setup is called dual control.
And finally, availability threat. This is probably the least obvious area which for some people does not even look like a security subject – mistake! The availability threat is even more real than the confidentiality one. Imagine a situation when there is a serious bug found in production which must be resolved as soon as possible. Developers find the problem and now they know how to fix it. As a first instinct, the easiest and fastest way to do it, especially during an emergency, is to give the developer access to production servers to finish the work and get back to normal. This is a completely wrong approach. What happens with the next release? There is a good chance that the fix will not be included because the developer forgot. It would never happen if the fix was delivered by DevOps because the update will go through a full release process. Such a condition is called separation of duties.
Without implementing dual control and separation of duties in development operations, application security looks like a cheap self-published book: you can read it and understand the text, but there are a lot misspellings and inaccuracies. It’s easy to find self-published books at Amazon by just looking at the price: professional publishers cannot afford to sell their products for $0.99. Sooner or later, hackers will find a “self-published” app on the web using their tools. Thieves always look for the low-hanging fruit.
