It is difficult to overstate the importance of software security. Modern server side software faces numerous security challenges. It can be difficult to navigate all of the different potential security threats to a deployed application. And unfortunately, in most cases, it takes just one chink in the armor to infiltrate an otherwise secure system. And worse still, the impact of a security breach can be massive.

At FP Complete, we believe that security must be an integral part of all activities around software: requirements, project planning, architecture, development, quality assurance, deployment, and operations. While there's too many details to capture in a single page, we're going to give an overview of some of our general recommendations around improving security.

If you have concerns around your security and would like to set up a consultation, please contact our team.


One issue with security is the lack of clarity around what it means. Security is a broad, encompassing term. One person on a team may think of security as "make sure only licensed individuals are able to use our software." Another may think "ensure no user can read another user's data." And a third may interpret it as "don't let users upload viruses that will infect our servers."

These are all valid security concerns, and many more of them exist too. Ensuring only authorized users access machines, preventing common web exploits in software, preventing social engineering attacks, and much more fall into this umbrella.

During the requirements phase is a project, it is vital to consider as many of the security requirements as possible, and ensure the team leads are all in sync on them. And this list of security requirements should regularly be reviewed as needs change, products develop, and new threats come to light.

Project planning

When planning a project, most teams know to estimate and schedule time for basic feature development. Well planned teams will also include budget for debugging, quality assurance, documentation, and project management. However, security is often missing. Many assume this is part and parcel of other activities. After all: developers should be coding with security in mind. The quality team should be exploring potential security vulnerabilities.

Skilled and experienced software and quality engineers will do this. But there are two things to keep in mind:

  • Not all engineers have specialized skills in security
  • Without sufficient time in the budget, engineers may overlook some details of security

We recommend including explicit items in the budget, and ideally specific trained individuals, to focus on security. This usually falls to the Quality Assurance team. While on large projects, we would recommend a dedicated security team, a QA team typically has the correct purview and attention to detail to bring security to light. We'll further discuss quality assurance below.


It's much easier to design a secure system than to retrofit security onto an existing system. When there is sufficient time in the budget to address security, and the major security requirements are well known, we can architect correct solutions.

A common mistake is to think of this architecture work as being the responsibility of one team. For example, some people think of security as the purview of the deployment team. Others consider it to fall squarely on software development's shoulders. The reality is that, working in isolation, no one team can architect a secure solution. Detailed discussions of assumptions and expectations are necessary.

As a simple example, consider a web development project consisting of an infrastructure, front end, and back end team. The front end team may implicitly be making some assumptions around cross domain requests they can make. Unbeknownst to them, the infrastructure team may be planning on hosting static files on a CDN served from a different domain name, violating browser security policies. The back end team may end up "solving" the issue by applying Cross-origin resource sharing (CORS) headers. While the software may work, vital security assumptions may have been violated, opening up the software to attack.

Spending an extra few days at the beginning of the project can save months of wasted effort down the line. It can also potentially prevent company-destroying security exploits.


By sheer numbers, software is likely the largest source of security vulnerabilities. This can come down to mistakes (bugs), lack of clarity in requirements, poor communication between teams, and lack of understanding by developers. Remember that most developers are not by nature security experts.

In addition to the steps above (defining requirements, scheduling security time, and architecting good solutions), we recommend two powerful tools for improving development security:

  • Provide security training to the team in the form of courses, best practices documents, and code review sessions
  • Choose tools that support good security practices out of the box

For the second: we too often see companies choosing software languages and frameworks based exclusively on what will get them to market fastest. This is most often a misleading metric. The majority of software development occurs in the maintenance phase, not initial development. Languages and frameworks which focus on easing the maintenance burden, especially around security, are vital. Our Vice President of Engineering, Michael Snoyman, spoke about this in his talk "Functional Programming for the Long Haul".

This is one of the reasons why FP Complete builds software in Rust. Rust provides a great ability to get working code out quickly like Python or Ruby, provides the efficiency at runtime of languages like C and C++, and provides a strong type system to encode invariants like Haskell or Ada.

If you're interested in learning more, please check out our training solutions.

Quality Assurance

If you have a large enough project, it's worth having a dedicated security team to review the entire software and DevOps stack holistically and bring their experience to bear on recommendations. However, for smaller projects, a dedicated team may not be warranted. Including security overview as part of Quality Assurance's recommendations can be a workable solution. QA already has scope to review the totality of a project. And given clear sets of requirements, a QA team can put together proper acceptance criteria and tests plans to cover these requirements.

Even in such a setup, it's a good idea to include some dedicated security investigation via a penetration testing team. This may uncover gaps in the requirements that a quality engineer would not know to look for.

We also recommend leveraging multifaceted testing to get the most bang for your quality buck.


Many of the best practices FP Complete recommends around DevOps will help ensure a secure deployment. Immutable infrastructure, infrastructure as code, containerization, and CI/CD all help ensure that your software is in a known state, network architecture is configured correctly, and testing matches the production environment.

Another common security hole lies in authentication and authorization. Ensuring secure passwords, non-reused credentials, multi-factor authentication, and deterrents to social engineering attacks are all vital. We cover some of these topics in Understanding Cloud Auth.

Keeping in mind that security is a multilayered approach, there are some additional ideas you should consider, such as leveraging application firewalls to automatically detect and protect against some classes of attack. This can be a good double-check on software security.


The operations team needs to have useful information to help protect a system. Importantly, this means:

  • Log aggregation for investigating events
  • Monitoring to collect useful information
  • Alerts to notify of suspicious activities

There are many software packages out there to help with these activities. Once you have the software available and installed, configuring correctly is its own challenge. You can read more in our article on logging, monitoring, and alerting.

The operations team is the first line of response against an actual intrusion. While we do everything to prevent a successful attack, it's best to plan in advance for how to respond. Having intrusion playbooks and training for the operations team will hopefully be unnecessary investment. But if there is an attack, you'll be very glad for the insurance.

And finally: while the entire team should have social engineering attack training, the operations team is the most at risk for these attacks. If only one group will receive such training, it should be them.

Learn more

FP Complete specializes in secure, reliable, and efficient server side software, and getting your product to market quickly. Want to learn more? Check out our DevOps homepage or contact us for more information.