When the unlimited vacation policy doesn’t work

Many of us startups provide what we call unlimited or flexible vacation policies, with the goal being to take as much time off as you need, as long as it’s manager approved and you can get your work done. There are so many pros and cons and I’ve seen so many people ask why to have or not to have an unlimited vacation policy in place. 


Most people think that unlimited means people will take off all the time. And, yes, we have seen that happen on some very rare occasions. We do have a policy, for example, that interns no longer get vacation during their stint at Tinfoil. Internships are typically 3 months and have a set project. If an intern takes off too much time, they’re less likely to finish the project in the scoped out time. That doesn’t mean if all of their friends are going to Yosemite they can’t, but we don’t advertise vacation for them. 

What we’ve actually found for the flexible vacation policy, though, is that usually we see the opposite of most founders’ concerns: employees don’t take nearly enough time off to avoid burnout. There are lots of different things we’ve implemented in order to make our flexible  vacation policy work. The first thing we implemented was holidays. We try to have one holiday a month. Sometimes those are just fun, silly holidays like Pi Day, and other times they’re your standard federal holidays, like Thanksgiving. On occasion, they’re things we’re going to do together, like Tinfoil’s Anniversary. We try to make sure holidays are spread evenly throughout the year and allow time in conjunction with both weekend and weekdays throughout the year to break up the normal routine.

When we implemented holidays, the policy was that you could still come in to work, but shouldn’t expect anybody else to be in the office. Initially, many employees still worked holidays, but it eventually got to the point where we realized that we should really take those holidays off. We started to and we noticed a drastic drop in stress and burnout levels.

Once we implemented the holidays, we still had a couple of issues where some people were still going to the normal rhythm. They wouldn’t take longer vacation and, though the holidays helped a lot, they didn’t fix the entire problem. Part of what we noticed was that if someone did something outside of their normal routine on a weekend, for example, if they traveled or did something unique that they didn’t normally do, they typically got to the point of burnout way less frequently. This led to a solution: we took a handful of holidays (typically holidays such as Pi Day, that employees weren’t already traveling for or doing atypical events for) and called them special holidays. We’ve been beta testing special holidays for 2-3 years and they work wonderfully. 

For a special holiday, we give you up to $60 to go out and do something outside of your typical routine. This could mean going camping, kayaking, skydiving, getting a fondue as a group… anything you wouldn’t normally do. Of course, we have had to create guidelines over time. We reimburse up to $60. If it’s under $60, that’s ok, but we ask our employees to be honest and we’ll reimburse up to the amount they actually spent. There are some things that we’ve rejected, as well. As always, you have to be flexible and revisit your policy over time. For us, we saw some employees doing the same thing every special holiday. We eventually made the rule of there needing to be at least a 12-month gap between repeating the same event or activity. 

We did have to implement a few guidelines at the beginning, based off of questions employees asked. For example, if you want to host a party, that’s OK, but if you want to play a bunch of board games, you can’t buy six different games on the company and call it good. We wanted this to be for experiences, and not for physical items. We encourage employees to use it in a manner in which they can actually experience something that they wouldn’t usually do. We found that, when people actively partake in this benefit, they tend to come back refreshed and get excited about what they did, whereas those that didn’t do anything new don’t have the same level of “refresh.” People excitedly talk about the things they did and others end up wanting to do that experience the next time, so we have a page on our internal wiki to add fun weekend ideas to share with others. This is great for team bonding, great to make sure that people don’t hit burnout, and it’s one of the few things we’ve added to make sure our unlimited vacation policy works. 

It’s true that every so often you’ll see somebody taking advantage of any policy you have in place that’s beneficial to them, but, on average, we believe our employees are honest, faithful, and act with integrity. Often, you’re going to see that unlimited vacation expectations are set by the top. If your management is not taking enough of a break, your employees won’t take enough of a break, and everybody will suffer. There are lots of little things you can do to make this policy successful. What have you found? Have thoughts on how we could improve our policies or new ideas we can try? Email me anytime with suggestions!

Ainsley Braun

Ainsley Braun is the co-founder and CEO of Tinfoil Security. She's consistently looking for interesting, innovative ways to improve the way security is currently implemented. She spends a lot of her time thinking about the usability and pain points of security, and loves talking with Tinfoil's users. She also loves rowing, flying kites, and paragliding.

Pluses and Pitfalls of Repo.stream

Scenario: you are working on a phoenix app that has seen a good deal of use and need to do some transformations of some tables encompassing an exceptionally large number of rows and their relations. Obviously, some amount of considerations for performance are necessary; if you can avoid loading an entire table into memory in order to achieve this, that would be ideal right? Enter Ecto.Repo.stream, turn that giant list into a lazily evaluated enumerable and load rows as needed. Job done, right? Well, depends.

The good news is you will definitely address the issue of memory use, however it does come at the cost of time, which can increase greatly if, for instance, you need to access a number of rows in an associated table for every row you are referencing. For instance:

This might seem like a good idea, if there are large number Bar’s for every Foo entry, but since the stream must be inside a transaction, you have one connection you’re working with to finish enumerating over the stream. This can be adjusted with the :timeout option on Repo.stream which can be relaxed from its default at 15000 milliseconds all the way to :infinity, but if your streaming changes rely on a flaky connection or some other piece of code, you could run into an issue again on that side. Safer to avoid nesting streams if possible, or to find a different way of chunking data.

If memory is a more pressing constraint than time, Repo.stream is a pretty convenient way to manage how much is loaded into memory at a given time. Just remember to choose an appropriate timeout value before you start.

Alex Bullen

Alex is Tinfoil Security's Top-Shelf Programmer (and fetcher of things from high shelves). A former psychology wonk and recent App Academy grad, Alex endeavors to treat every challenge as an opportunity to improve his code-fu. When not busily building blocks of precisely put code, you can find him reading fantasy novels or practicing kung fu.

Dockerfiles for Phoenix

While a lot of our older software was written in Ruby and Ruby on Rails we've been expanding the past couple of years into Elixir and Phoenix (Elixir's batteries-included web framework). Docker remains our preferred mechanism to deliver our software in a well-tested and repeatable format. I'd like to share with you a simple Dockerfile for Phoenix, specifically supporting Phoenix >= 1.4 which uses webpack instead of brunch.

We're using a multi-stage to keep the image slim and nimble. In the first step we get a copy of the Elixir dependencies, mainly for the phoenix and phoenix_html Node modules that are co-located in the Elixir Hex packages. The second build file lets us build and emit the finalized assets with webpack. In the final step we're back to an Elixir base image and we can copy everything over, merge the assets, and set the command for starting the server.

This produces an image around 100MB. Compared to our Slim Dockerfiles for Rails that's a space savings of 50%! We've seen some pure-Elixir applications even smaller when you use Distillery to create an optimized release, which we'd recommend for heavier production use as it gives you a lot more control.

I hope you enjoyed seeing an example of building a slim Docker image for Phoenix. If you'd like to help build next-generation security software and work with Elixir and Phoenix daily check out our open job positions!

Ben Sedat

Ben Sedat is the Engineering Wizard of Tinfoil Security. He's a bit of a blend between a traditional software engineer (builder) and security engineer (breaker). He spends a lot of time thinking about security: both detection as well as creating solutions for the security issues that exist in software and the internet. He also plays lots of video games. Lots.

Awesome Possum

Our team is like a small family. We try to encourage everyone to get to know everyone else. Unfortunately, as with any business, sometimes sales, marketing, engineering, and all the pieces in between don’t collaborate as much as they could. As founders, we appreciate every employee, but sometimes the new engineer doesn’t really know what the new sales person is doing, nor how they can help.

Enter: the awesome possum. For a while, I’ve been thinking of ways to encourage people on our team to collaborate with others they normally might not collaborate with, and how to encourage people to show appreciation for the help they receive. That’s then I came up with the idea of the awesome possum. The awesome possum is a little stuffed possum. If you have the awesome possum, you pass it along to the next person who does something awesome (out of their job scope or truly exemplifying a Tinfoil value) for you or someone else. They, in turn, pass it along. There’s no time limit for holding the possum, so you could have it for a minute or a month.

When I first showed up with the awesome possum everybody laughed. Now, he’s dressed more dapperly than I am and always in a new Tinfoil hat. It might be a small thing, but it’s just one way for each of us to show appreciation across the team. There’s a lot of joy when the possum ends up at the other end of the office, circulating amongst a new team.  A little out-of-the-box thinking goes a long way.

What great hacks have you implemented on your team to encourage collaboration or appreciation? I’d love to hear them!

awesome possum

Ainsley Braun

Ainsley Braun is the co-founder and CEO of Tinfoil Security. She's consistently looking for interesting, innovative ways to improve the way security is currently implemented. She spends a lot of her time thinking about the usability and pain points of security, and loves talking with Tinfoil's users. She also loves rowing, flying kites, and paragliding.

How to Choose a Web Application Scanner: DAST, SAST, RASP, IAST, HAST...Holy SaaS!

Five penetration testers and five developers walk into a bar. Not just any bar, but a bar that serves up the finest automated web application security scanning cocktails you can find. The bartender asks the first penetration tester, “What’re you drinking?” NoName Hacker responds that he would like the SAST. The other pen-testers scoff at this. One claims that his skills for manual testing outweigh any tools at this bar. Apparently his home-made scanning cocktails made with age-old moonshine are the best. Another screams that SAST is inefficient since it requires customizing the scanner to the application’s stack. Now it’s time for a developer to step up and order. The crowd is screaming behind her, so what should she do? What would you do?

Imagine what the inventory of this bar would look like for a minute. It’s probably similar to a World of Beer with 550+ beers on tap, except instead of Hefeweizen, Kolsch, IPAs, and Stouts, we have DAST, SAST, RASP, IAST, and HAST tools. Oh, and I almost forgot, the huge list of open source tools that exist. Making a decision is a nightmare. Everyone has a different opinion, and what works for NoName Hacker might not work for the Developer Code Queen.

So where should you start? 

It’s best to decide whether or not automating Web Vulnerability Scanning is important to your organization. As with many business functions, automation saves time and money. Your solution needs to increase the efficiency of your organization’s Software Development Life Cycle (SDLC). But, since you are reading this, you have probably already decided that you can save money and time, which means more money, by automating your scanning and avoiding continuous manual application penetration tests.

Just to pound this home, imagine that your application contains merely 50 different entry points and you want your security engineer to test for 10 different vulnerabilities that have 10 variants each, each week. That’s a total of 100 tests for each of the 50 entry points. If a single test takes 3 minutes, your security engineer will be testing your application for 52 hours per week every work week of the year.

It’s time to choose an automated solution. 

What should you look for and where should you start? There are a few areas to focus on:

  1. Implementation
  2. Integration
  3. Scale


You are busy and you need a solution that implements easily. It should be simple to deploy, accurate, secure, and give usable and actionable information. A tool that is complicated and timely to learn will waste more time. If you spend an extensive period training an engineer on a complicated tool that you spent a ton of money on, you will have to repeat that process when, not if, that engineer eventually moves on to another project or to a different company.

Determine what stack you are running. If you decide on a SAST, RASP/IAST, or HAST solution, there will be several steps in the implementation process that require you to customize the scanner to your stack. Are you a modern organization running several apps on different stacks? Perhaps this isn’t the best solution for you.

A quick example: Elixir has boomed in popularity since it first appeared on the scene in 2011. The scalability and speed of Elixir and the Phoenix Framework make it popular for building web applications, APIs, and the like. Or maybe you are using Go. Your static code analyzer would have to continuously update to your stack, and you will have a tough time finding a tool that supports this modern language with the granular accuracy you need. RASP and IAST tools also require you to install a dependency on every single web server that you are running, adding infrastructure pain. Because of this and the stack-specific nature, it adds latency. 

Some tools will openly state that they have low CPU impact, say, less than 4%. FOUR PERCENT?! That’s huge latency if you are someone who cares about latency like a bank. That type of latency is simply unacceptable.


Imagine a world where you have a vulnerability scanner that not only automates the scanning for vulnerabilities, but creates a ticket in your bug tracking tool containing vulnerability information. Once developers verify and fix the vulnerability, they kick off a rescan using the API. The scanner identifies that the vulnerability is indeed fixed, and automatically closes out the ticket. Months later, the team builds an update and runs a scan which finds the same vulnerability has reappeared. The process starts again with automatically creating the ticket, but instead of creating a new ticket, it reopens the past vulnerability tickets containing all of the history.

Does it sound amazing? Great. Because it’s not just a dream, it is reality

Your scanning solution MUST integrate and enable your CI/CD processes. Look for something that connects to Jira and Jenkins (or any other ticketing and build tools you use) and automates the tasks of creating tickets, provides developers the details needed to verify that the vulnerability is not a false positive, and closes out the tickets once a vulnerability is fixed. 

Can the tool scan staging and live servers?

Are all of the features and data available through the API?

Does the scanner output results in XML or JSON?

Scanners that iterate over the application’s source code, such as SAST and elements of RASP/IAST do not interact with the application like a hacker would. SAST does not run against an actively running application and only looks for things that look like a vulnerability, but which might not actually result in a run-time vulnerability. False positive alert! 

You know your processes better than anyone, and you know what your applications look like. Find a solution that makes your developers’ lives easier, not one that overloads them with a high number of false positives.


Your tool should be easy to scale with your organization. Perhaps the first initiative is to scan the top 10 most critical external facing applications. But the long-term vision is to integrate scanning into the development of all 50 of your applications. The implementation and integration considerations above apply to each and every application you manage. The easier the training and deployment for the first application, the more time you will save in integrating the solution into your entire organization.

DAST tools do not require customization for scanning your stack. They interact with your website and find vulnerabilities that actually exist. At Tinfoil, we built our scanner with the goal of creating an automated solution that scans your application like a real hacker. It is simple to get up and running, and you don’t need to spend weeks training on the functionality. You can scan 50 different applications running Elixir, ASP.net, PHP, Angular, React, Ruby, Node.js, Go, and any other language your heart desires. The setup will be the same, and you will save many many headaches.

Now it’s time for you to do some work. 

Before getting free trials and evaluating everything on the market, prepare your team so that you increase efficiency. High speed, low drag… am I right?

  1. Take an inventory of your web applications. Identify the most critical to scan first, and consider the implementation issues we talked about earlier.
  2. Look into the tools that you use in development. Make sure that the solutions you test integrate easily into the workflow you already have in place.
  3. Decide what is most important to your organization. Do you want the cheapest solution to check the box? Do you want the most expensive solution that comes with all of the doo-dads and frillies that make your security engineers heart’s race? Do you want to increase efficiency through high quality integration and automation?

Keep in mind that not every tool is built equal. As we have already seen, the process is different for each classification of a tool. But even more important, each tool in that category was built to satisfy a need using a different methodology.

Okay time for my shameless plug: Tinfoil Security’s DAST is, bar-none, the cream of the crop for DAST tools. It is premier in performance, simple to learn and deploy, and integrates seamlessly. 

We also offer a patent-pending API scanner. There is no other API scanner on the market that truly interacts with your API like a hacker would, finding vulnerabilities and scanning for best practices. To learn more about this, see how to scan APIs the right way.

Are you interested in seeing a demo of our web application scanner or API scanner? You can set up a demo here. Use that link also if you need tips on good hair products, or to hear the rest of the story with NoName Hacker and Developer Code Queen.

Stay classy.

Derek Jackson

Derek Jackson is the Generalissimo of Dark Arts, or more 'corporate' termed, the Public Sector Channel Manager. He spent the last 4 years going "pew pew" in the US Army doing intelligence work for infantry battalions and special forces. He deployed to Kuwait, Jordan, and Syria with 1st Special Forces Group (Airborne) where he did some pretty cool things. He recently completed his M.B.A. and intimately knows security from those green suit days. When he's not in the office, he likes teaching his baby son how to drum, eating fine foods, archery hunting, doing triathlons, and achieving any other goal that sounds crazy.