Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Application Security

8/13/2020
02:00 PM
Guy Podjarny
Guy Podjarny
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
50%
50%

Secure Development Takes a (Remote) Village

The shift to work from home isn't just about giving your Dev team the physical tools they need.

Development is a collaborative process. Yes, it requires stretches of focused time to create, but all developers heavily depend on their teammates to help plan the right solution, build the different components in it, and review any changes made. Furthermore, the development team needs to collaborate with the rest of the business to make sure its creation achieves the outcomes they all aim for. 

This collaboration has been shaken up by the full-time remote work forced upon practically all developers as a result of COVID-19. Some teams are better equipped to handle it than others, but few are truly immune to the change. The complete absence of in-person whiteboard sessions, hallway conversations, and friendly chats by the coffee machine means we now have to adapt how we work together to create and deliver great software.

Security is at an even greater risk of being ignored. For starters, risk is naturally invisible, making it all too easy to overlook it. Secondly, the practices of secure development are still being formed, and now require more careful hand-holding. Last, the collaboration between development and security teams is often not great in normal times. Today, collaboration can easily worsen now.  

What's needed? We must make a concentrated effort to secure development while working from home. Below are five best practices that both dev and security teams should adopt:

Practice 1: Empower developers to build with security front of mind.
To encourage developers to build with a security-first mindset, they first need to understand what good looks like and what is expected of them when it comes to cybersecurity. The best way to do this is to provide developers with comprehensive guidelines for security processes. This will allow them to move items forward without having to stop and wait for approval. Empowering developers with such responsibility will help them to feel more confident that they're ultimately building fully secure applications because they asked the right questions along the way. 

Practice 2: Invest in security visibility
You can't empower developers to embrace security without giving them visibility into the critical vulnerabilities. Here are a few ways to do that:

  • Build a detailed software bill of materials (SBOM) for each application so your dev team knows if any newly disclosed vulnerabilities will affect their in-progress projects.  
  • Raise awareness of vulnerabilities discovered in builds that weren't severe enough to break it to the full team — either in Slack or an equivalent internal communications channel — so you can avoid repeat mistakes across teams.
  • Create leaderboards showing how well different teams are handling security issues. This is a fun way to stoke competition while learning from each other.

Practice 3: Instead of breaking the build, fail pull requests.
Breaking the build due to a security violation is a popular CI/CD security measure, but it's also disruptive. This is especially true when working remotely as it takes that much longer to figure out the problem and get it resolved. Instead, fail pull requests — this has several advantages including: 

  • They allow you to test only the new code changes, which should be within the developer's control to fix. 
  • They're more local to the branch where code is modified, empowering developers, and maintaining individual autonomy.
  • You can choose whether a fail pull request blocks a merge or is just informational, again allowing developers to make their own judgement calls.

Practice 4: Partner up!
To help remote developers know whom to turn to when they have a security question, match up individuals from security teams with a dev person and vice versa. Building these one-on-one relationships will create a stronger overall rapport between the two functions.

Practice 5: Focus on security basics first.
It can seem counterintuitive, but when it comes to security, prioritize the basics before the esoteric attacks. Scaling how well you handle vulnerable components, configuration mistakes, and leaked tokens should take priority. Once your remote dev teams have ticked these boxes, they'll be better equipped to tackle more involved, multifaceted security challenges as they emerge.

Practice 6: Improve SSH security.
As more machines go remote, the risk of a developer machine getting compromised is higher. These dev machines often have access to sensitive systems, such as source code repositories or production systems they can SSH into. These three steps can help to more effectively secure those channels to mitigate potential damage:

  • Enable mutual key-based authentication. 
  • Enable or reduce session timeouts. 
  • Enable stronger identity-based authentication. 

Practice 7: Bug Bounties
Bug bounties are a good way to add an extra layer of security assessment capability. Check out Bugcrowd or HackerOne —they can guide you through much of the process of setting up your own program if desired.

The shift to remote work isn't just about making sure members of your team have the physical tools they need to work away from the office. It's about recreating the positive aspects of an office environment so that developers can achieve great results by collaborating with their chosen "village."

Related Content:

Guy Podjarny (@guypod) is a cofounder at Snyk.io focusing on securing open source code. Guy was previously CTO at Akamai following their acquisition of his startup, Blaze.io. Prior to that, Guy worked on the first web app firewall & security code analyzer, and dealt with ... View Full Bio
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Commentary
Ransomware Is Not the Problem
Adam Shostack, Consultant, Entrepreneur, Technologist, Game Designer,  6/9/2021
Edge-DRsplash-11-edge-ask-the-experts
How Can I Test the Security of My Home-Office Employees' Routers?
John Bock, Senior Research Scientist,  6/7/2021
News
New Ransomware Group Claiming Connection to REvil Gang Surfaces
Jai Vijayan, Contributing Writer,  6/10/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: Zero Trust doesn't have to break your budget!
Current Issue
The State of Cybersecurity Incident Response
In this report learn how enterprises are building their incident response teams and processes, how they research potential compromises, how they respond to new breaches, and what tools and processes they use to remediate problems and improve their cyber defenses for the future.
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2021-31476
PUBLISHED: 2021-06-16
This vulnerability allows remote attackers to execute arbitrary code on affected installations of Foxit PhantomPDF 10.1.3.37598. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the han...
CVE-2021-31477
PUBLISHED: 2021-06-16
This vulnerability allows remote attackers to execute arbitrary code on affected installations of GE Reason RPV311 14A03. Authentication is not required to exploit this vulnerability. The specific flaw exists within the firmware and filesystem of the device. The firmware and filesystem contain hard-...
CVE-2021-32690
PUBLISHED: 2021-06-16
Helm is a tool for managing Charts (packages of pre-configured Kubernetes resources). In versions of helm prior to 3.6.1, a vulnerability exists where the username and password credentials associated with a Helm repository could be passed on to another domain referenced by that Helm repository. This...
CVE-2021-32691
PUBLISHED: 2021-06-16
Apollos Apps is an open source platform for launching church-related apps. In Apollos Apps versions prior to 2.20.0, new user registrations are able to access anyone's account by only knowing their basic profile information (name, birthday, gender, etc). This includes all app functionality within th...
CVE-2021-32243
PUBLISHED: 2021-06-16
FOGProject v1.5.9 is affected by a File Upload RCE (Authenticated).