This is part of a series about essentials for developing R&D applications — the seemingly small things that are easy to overlook but make your project go much more smoothly. Be sure to check out our articles on documentation, repeatability, testing, and automation.
With new cyberthreats happening everyday, a vigilant approach to security is a necessary part of any project.
Security is part of every layer of the development process, including the following:
- Infrastructure and operating system: The Operating System you choose, standing up servers, and installing system packages your applications depend upon
- Programming language: The code itself, as well as the version of the programming language with which it’s written
- Browsers: Checking for outdated browser versions and potentially restricting access to certain users
Since vulnerabilities can occur in every layer, it’s important to test in each of those areas as well.
Covering the basics
It’s important to note that security is an ongoing effort. New vulnerabilities are found constantly, and best practices are always evolving. Even with great vigilance, nobody catches everything. That’s why bugs exist in software, and some of those bugs can create security vulnerabilities. Often, the vulnerability isn’t even in your own code but in a 3rd party dependency your application depends on. This is why automated tools exist to scan and report on these potential vulnerabilities.
The best way to cover the basics is to have a security expert audit, whether that’s a dedicated member of the project team or an external group. Either way, the person or team auditing should be different from those who are building the project. It’s a basic security standard to have somebody to find vulnerabilities and ensure that things are secure. This person verifies that whoever built it did their best to meet security requirements and will remediate anything that’s found.
Security matters with each layer. Once you get into a highly regulated field like healthcare or banking, you really need to be cautious. Especially in these industries, it’s common practice to have people dedicated to it.
Developers should be comfortable coordinating with the security team to ensure that they perform routine audits and that there’s a workflow in place to guarantee they’re establishing the right documentation. This allows you to show that you’re routinely making updates based off of your security scans and that vulnerabilities are not recurring. It’s an ongoing process that requires dedication.
Even if you consider a project to be low risk or lack sensitive information, there are still ways in which you can be compromised. Sometimes breaching one area of the system can lead to a cascading effect where the rest of your systems can be compromised. Maybe it’s enough that your reputation is damaged because content got altered on a static site you don’t think about often. Security should be taken seriously at all layers and with all systems.
Security tools
To address security with the appropriate level of comprehensiveness, you may want to consider one of the many robust tools that can scan an application and provide a great deal of results. These tools include the following types:
- Static code analysis tools scan your code base and report likely vulnerabilities. This can be incorporated into a build pipeline to ensure you never release code that has these known issues.
- Server software can automatically find and update packages that report security vulnerabilities.
- Server traffic monitoring tools can identify and report suspicious activity patterns. Some will even proactively block specific types of traffic, whether from known malicious IP blocks or by issuing a verification test such as CAPTCHA when the traffic looks like it may be from a bot.
- External scan tools will check whether your server and application are exposing information and ports they shouldn’t be, creating possible vectors of attack.
- Code level protections against malicious user behavior. Sanitizing user input, locking out users, and enforcing password security best practices are a few examples.
Looking to comply with SOC II or HITRUST keeps you honest and forces you to engage because you’re obligated to bring in an auditor and demonstrate it as part of the process.
When to audit
The more you can be in communication with a security team while you’re developing, the better. During development, it’s helpful to provide a list of the software packages that you’re using, schedule scans, and give visibility into your code base.
It’s also essential to plan a full security scan at release to check that everything is running properly. There may be things that aren’t found in development because not everything is configured identically to production. Or maybe you scan it and realize that you accidentally released the application using your development settings. Maybe your logging is too verbose or isn’t filtering out secure info.
In addition to scanning once you reach production, it’s critical to schedule routine scans after that. What may have been secure a month ago may no longer be due to new security vulnerability discoveries. Establish a cadence of communication with the security group. They’ll likely have their own guidelines and expectations. It’s common to scan once a month and have a monthly meeting to review the findings and come up with an action plan.
If there’s something that needs remediation, pull in project managers as well so that they can understand the scope of the work that needs to be done for meeting security standards and how it affects new development workstreams. Open dialogue is critical to setting proper prioritization and not derailing initiatives.
Communicating a vulnerability
When a vulnerability is discovered, it’s essential to have an established process in place for handling it. This often starts with assigning a severity to the vulnerability. Minor ones may be permissible to take several weeks to address, whereas severe ones may trigger a full Disaster Recovery Plan (DRP) including escalation to leadership and possibly having to publish a PR notice. The security team should have these various categories of risk, Service Level Agreements (SLAs) for time to remediation, and levels of escalation defined.
Be Prepared
We can’t stress enough how crucial it is to be aware of security issues and to have several precautions in place. Taking the time to understand the best practices for security during the development process is an essential step in protecting your software from malicious actors.
If you take proactive measures to protect your R&D projects from inception through post-production phases with rigorous vulnerability testing, you can help strengthen your organization’s security posture both now and into the future. To learn more about essential elements of software development, be sure to check out our other R&D articles.
Justin Bantuelle balances the responsibilities of both the Chief Operating Officer and the Web Technology Director after having worked with Health Connective for more than a dozen years. Justin regularly leads the cross-disciplinary teams in building out and updating applications for Fortune 500 companies.
Justin keeps his technical abilities sharp by contributing to an eclectic mix of open-source and personal projects on Github.
Jared Johnson
Jared builds innovative healthcare brands through digital strategy and engaging content that turns heads. He is a keynote speaker, prolific content creator, host of the Healthcare Rap podcast and author of Connect the Docs: Put Digital Health Into Practice.