Secure Coding At Axelerant: Best Practices

With well over 100+ engagements with recognizable partners, we’ve been overcoming common challenges to transform new ideas into market realities. Whether an incomplete product or a poor user experience, Axelerant has been accelerating product development with agility. With Intelligent design engineering, total workflow transparency and a success management framework, we’ve been building our clients’ dreams into a reality. 

All this is possible because our developers are deeply involved in the Drupal community to remain up-to-date with the current standards. They are prepared for all eventualities, including zero-day exploits, and an aggressive patching schedule. And this is true not only to our experienced developers but also to our newly hired team members because understanding, accepting and adapting to Axelerant's coding security guidelines is a part of every team member's induction process. Additionally, our leaders undertake programs and actions that encourage learning and sharing knowledge. 

Why? Because gone are the days when all you had to worry about was exploits at the operating system level. Now, based on how microprocessors are coded, we have to worry about even hardware exploits and security breaches. Security being a complex, ever-changing topic, tech leads at Axelerant are always in touch with the latest trends and updates in security fields, and whether or not it applies to us.

Axelerant's Coding Security Policies

To start with, our team members are familiar with and follow best practices and processes because a web administrator access to websites, working on source code, and access to servers (SSH/shell, file system, database), carries a high level of responsibility and trust.  So, usage of Axelerant developer accounts is:

• Directly related to a team member’s work with Axelerant, personal use (including personal projects) must be approved in advance by the Chief Information Officer (CIO)

• Use in any way harmful to Axelerant or our clients is forbidden

Web administrator account holders (Drupal) are:

• Familiar with how to maintain configuration security (drupal.org/security/secure-configuration)

• After changing site permissions, the site is tested by logging in as a user with each affected role and ensuring that access is limited correctly

• After changing settings affecting content/data access control, the site is tested to ensure the settings are correct

• The use of PHP in the web administration interface is strongly discouraged (as this code is harder to find and hence audit)

Developers, themers, and site builders working on the site codebase (and committing code to Git):

• Employ Drupal’s security best practices for defining roles and permissions and employ the rich landscape of contributed modules for Drupal to further harden permissions even at a field level.
   

• Follow best practices in building multi-stage multi-approval workflows for content publishing which allows large editorial teams to work seamlessly and securely with Drupal.
   

• Ensure their own code follows Drupal coding standards (drupal.org/coding-standards) and security standards (https://www.drupal.org/docs/develop/security), and is well abstracted and commented throughout; the project technical lead is responsible for reviewing all new/modified code each sprint, and ensuring it meets a high standard of quality.
   

• On the application front, our process includes checking the code through static code analysis tools that highlight potential security issues. These tools catch common oversights in using the Drupal's rich security API. The code is then peer-reviewed before merging to find any problems not detected by the automated tools. Reviewing all contributed code team members have not previously used encourages basic quality—this is not a formal security audit in most cases, but rather checking the usage stats, issue queue, skimming the module code for readability and adherence to good practices etc.; code that is actively used and maintained and follows best practices is less likely to have serious security issues. 

Our team members never merge a piece of code without having another developer review it. During this review process, potential security issues in the code that is written or the configuration that is built are brought forth and effectively fixed.

• We monitor the Open Source application advisories and get the critical security updates applied to the application within one business day. With “Service Area Leads” assigned to the technologies we work with, it’s the job of an assigned Axelerant Engineering Manager to ensure teams are staying up to date. Checking for security advisories (drupal.org/security) for modules used on each active development site and ensuring they are upgraded where necessary before the site is made live is an integral part of the process. Here, we also make sure the whole team is well-aware of the Drupal security modules, other security aspects, and, most importantly, security loopholes that may affect Drupal through various training and knowledge sharing programs.
   

• Leads also ensure the standard Dev-QA-Live process is always followed, such that all changes that may affect site security can be thoroughly tested before being made live.
   

• Understanding common attack vectors and the best practices for preventing them is critical to every developer's role. These include:

  • SQL injection, prevented by proper query construction and placeholder usage and preferring documented API over direct queries where feasible

  • XSS (cross-site scripting) attacks, prevented by ensuring user data is always sanitized as appropriate on output, even optionally using CSP

  • XSRF (cross-site request forgery), mitigated by ensuring URLs performing actions (including pages that process GET/query strings) carry an unpredictable token on URL generation

  • Session hijacking, prevented by using SSL and correct site/session settings

  • Data disclosure, prevented by carefully setting and testing access control not just at application but at the web server and OS level

  • Password guessing attacks, mitigated by using strong passwords and flood control policies
     

• Software that is not licensed under an approved Axelerant open source license may not be used on a project without prior approval from the legal team

Developers and themers maintaining local sandbox copies of client sites or working on the site vhost (SSH/shell, file system, database) are also upheld to similar standards and best practices. 

We are not just implementing DevOps but transitioning to DevSecOps. We will be doing mandatory steps in CI/CD to do SAST, DAST, Container scanning (twislock), secret detection, etc., and pass it as a stage.

Last but not least, our IT team system administrators working on Axelerant servers:

• Take the utmost caution when working on server configuration—document and test each change

• Non-urgent yet risky changes (those with a significant risk of introducing undesired side-effects) are only made when the person expects to remain online and available after the change

• Team members do not work on-site/user files as root - but "su" to the account first and only when required

• Promptly respond to alerts regarding the server and backup health 

• Team members ensure that offsite backups are transferred and stored only in encrypted form

• They also ensure the Hurricane Electric and RimuHosting access list (that controls remote hands and physical server access) is maintained

In conclusion,Axelerant takes a holistic approach to cybersecurity, from planning to implementation. We have an awareness that data of all forms, especially financial records, confidential data, and organization assets, needs digital and physical protection from hackers, disgruntled employees, script kiddies, and spammers.

Drupal is a proven, secure Content Management System (CMS.) And as a Drupal Agency Partner, our efforts are to take a robust approach to the security of our clients, partners, and their end-clients.