3 AppSec Lessons from Cloudy with a Chance of Meatballs
Maybe you’ve seen 2009’s Cloudy with a Chance of Meatballs. Perhaps you thought this was a movie about science and about a young nerdy-man trying to find his place in the world. Actually, the real purpose of this movie is to help teach you and other developers some very important Application Security lessons.
Recently, my toddler has been obsessed with the 3D animated movie Cloudy with a Chance of Meatballs. After watching this movie end-to-end nearly 50 times, not only do I now get all of the jokes, know all the Easter Eggs, and can quote the best parts verbatim, but I also saw the true parable at hand.
For those of you not familiar (STOP Now and watch this movie at least 3 times, you’ll thank me), here is the basic synopsis: The story focuses on the people of Swallow Falls, a small island town in the middle of the Atlantic and specifically on the protagonist, a nerdy outcast and inventor named Flint Lockwood. The town’s sardine fishing-based economy is on a downward trajectory, “just after everyone in the world realized that sardines are horrible.” Flint wants to save the town by creating an invention that will create delicious food so that the townspeople aren’t stuck eating the sardines that no one wants for every meal ad infinitum. However, all of Flint’s previous inventions ended in disaster and Flint’s father is against any further inventing. Flint half-heartedly convinces his father that this time will be different — but of course, after a bright start, things get out of hand and Flint’s invention causes catastrophe on an epic scale. Mix in a love story, the quest for a father’s approval, a no-good town Mayor, and a Monkey Thought Translator and there you have the story. Without too many spoilers: All ends well: Flint gets the girl and his Father’s love, and the Mayor gets his just desserts.
Okay, so what? A kid’s movie with a fairly predictable, but enjoyable, storyline that a parent can tolerate on an never ending loop. But let me assure you, there is more. As an AppSec educator, I couldn’t help but notice the many lessons we can take away from this movie. At the core of all of this food weather is technology, poorly tested and subject to new demands from the “business,” which of course need to be rushed to the market ASAP.
Sound familiar yet?
Lesson 1: Pay Attention to the Dangeometer
Okay, so you’ve hopped aboard the Agile train and on top of that you are an adherent to Test Driven Design (TDD). Even better, you’re all about shift left and you’ve even integrated linting and security code scanning in your CI/CD pipeline. All of this monitoring and checking is great, but there are three important caveats:
(1) You need to actually check these reports and
(2) You need understand what to do with the results of these scanners and
(3) you actually need to take action before the Earth is destroyed by giant pancakes and corn on the cob.
With this invention, unlike in the past, Flint is prepared: His water-to-food invention (the FLDSMDFR) is a complex piece of equipment that mutates water molecules into food based on code that Flint types at a feverish pace. Mutation sounds scary, right? Yeah…so that is why Flint built in a Dangeometer. Awesome. Except for this little exchange:
Sam: So you’re sure this is safe?
Flint: Don’t worry. I have a Dangeometer that lets us know if the food is going to over-mutate.
Sam: What happens if the food over- mutates?
Flint: I don’t know. But that’ll never happen.
As you may imagine, as Flint is pressured to push the limits of his invention further and further by the townspeople and the Mayor, the Dangeometer steadily grows from green, to yellow, and then deep into the red. Initially, Flint is concerned about the rather rapid increase in danger levels, but then over time he becomes less concerned and fearful, to the point of undervaluing and ignoring the warnings all together. Of course, by the time things are about to go full blown catastrophe we’re deep into the red and its too late to turn back.
Flint knew the importance of building tests and monitoring for his invention, however, he just barely did the minimum. Sure he had some unit tests and reporting, but he didn’t really understand what the risks were and what he should do as the danger level climbed. Going through the motions to satisfy some auditors or the CAB is great, but you need to remember that your application is not done when you push to prod. You need to keep your eyes on things and take appropriate and timely action to fix vulnerabilities and other problems, otherwise you end up with a big mess on your hands. A mess that you need to solve while simultaneously fighting-off mutate chickens and life-size gummy bears gremlins, #scienceproblems.
Lesson 2: The Pressure to Push
Throughout the entire movie you can see that Flint has his doubts. After the successful beta, Flint isn’t quite sure if his invention is ready for production. Within minutes of getting its first taste of full electricity, the FLDSMDFR begins to develop a mind of its own (think GLaDOS, but with food instead of lasers). However, Flint wants to save the town and make everyone happy, especially his father, and impress his love interest Sam. While he acknowledges his concerns, his drive to please takes control. He keeps pushing the FLDSMDFR harder and harder. His father, continually skeptical, continuous to discourage Flint from keeping things going. However, at the same time the Mayor sees Flint as his ticket to international fame and greatness (he wants to be a Big Mayor) and he manipulates Flint’s emotions to keep Flint’s machine going.
At one point, Flint tries to reason with the Mayor — this turns out to be the last opportunity for Flint to slow down or turn off his machine before he brings about a food apocalypse. He warns the mayor about dangerous over mutation, but the Mayor retorts:
The Mayor: Here’s what I heard: “Science, science, science, bigger.” And bigger is better. Everyone’s gonna love these new portion sizes. I know I do.
The mayor doesn’t care about risks, he has tunnel vision and only cares about his chance of greatness. When Flint responds that his dad thinks he should turn it off, the Mayor continues:
Geniuses like us are never understood by their fathers, Flint…Who needs the approval of one family member when you can have it from millions of acquaintances?
In the real world, rarely are we lone-wolf genius inventors. We are working to solve some business problem or meet some customer need. There is always the push to move fast and break things. Sometimes, the business doesn’t listen or we fail to communicate ( Science, Science, Science == ?!?!, but Bigger == Praise+1).
It takes great strength, and often comes at great personal risk, to speak up or go and blow the whistle. It takes some backbone, but we all play a part in managing the balance of "Creepy or Clever ." At the same time, one of the hardest skills for many developers is to learn how to communicate in a business- and not tech-centric way. A good way to start is to follow the money, not just today or next quarter, but into the long term where the repercussions may suddenly sneak up and magnify.
Flint’s internal struggle against that #yoloPushProd momentum leads to some really negative consequences. Flint fails to push back against the excitement and find a way to communicate the clear and present danger. He backs down down when he is made to feel small.
The beta was a true minimum viable product. Version 1.0 went out the door early, and there was clearly no load testing on that FLDSMDFR.
Lesson 3: The Importance of Training
After all jello-hell-o breaks loose, Flint needs to rely on his near-Luddite Father to help save the day by emailing him the “kill code” to turn off his machine-gone-run-a-muck with the world’s weather. However, his father, who runs a bait and tackle shop, isn’t at the same techno-nerd level as Flint.
Flint has made several attempts over the years to show his father his lab and inventions. However, his father has always turned down the opportunity. While in the short term this leads to Flint’s alienation from his father, when it comes to this pivotal point in the drama, his dad struggles to perform a simple drag-and-drop operation to send Flint an email.
There are a few lessons here:
Developers: It’s easy to code via StackOverflow and Google, but it is important to read the docs and to get proper training on security topics. Otherwise, when it comes time to take quick action you’ll be trying to figure things out under pressure and in a time panic.
Business People: While it’s not realistic for all business people to become techies, they cannot wall themselves off from the tech-side. Business people should understand the basics about how their systems work and the risks from the technical and business-process side of the application or system.
This is also the second time where we need to talk about communication. You need to properly document things. This not only helps in a crisis situation, but helps on-board new team members and ensure there is clarity between expectations and how the system actually performs.
A Few other takeaways
So far we covered the three big ones for you, but there are many other great security concepts (or lack thereof) demonstrated throughout the movie.
Let’s talk about some of the other big Security 101 misses throughout the movie:
- Flint builds this massively complex computer system, but he doesn’t bother with authentication. This allows the Mayor to sneak into Flint’s Lab and overload the system by ordering a “Vegas Style Buffet,” which kicks off the perfect food storm (Side note: The mayor didn’t seem to understand science, but now he is an expert programmer?). Had Flint locked down his system with proper authentication and authorization he could have stopped this malicious tampering which tipped the Dangeometer past the brink.
- Redundancy…redundancy. Flint relies on a satellite uplink to talk to the FLDSMDFR flying through the sky. Upon trying to undo the Mayor’s overloading of the system with the Vegas Style Buffet order, Flint gets into a physical fight with the Mayor that ends in the explosive destruction of his uplink relay, rendering it impossible to remotely communicate with the FLDSMDFR. As a result, Flint needs to risk a dangerous manual upload of the “kill code” by inventing a flying car and infiltrating the defenses of the FLDSMDFR which has mutated into a sentient being, with an army of mutant-food defenders to protect it. Spoiler: Flint runs into trouble with his backup plan because he is careless with the USB drive holding the “kill code” and the drive gets sucked out a broken window while flying to the FLDSMDFR. You have to have a backup plan that works and you need to use appropriate protections based on the value of a given asset.
To sum it up: Be prepared, be realistic, and be honest.
You need to stay on top of your code and ensure that your are doing the right thing for your company and your customers/users. You can push out something with great intentions, but at the end of the day remember your 7 Ps).
While it’s great to be the hero, it’s not so great to make a big mess in the first place. Keep that pasta on the plate and out of the sky.
Until next time, Bon Appetite.
