Bibliography DevOps DevSecOps-Security-Privacy Software Engineering SRE - Reliability engineering - Chaos engineer

B08CTGR1XC ISBN-13: ‎978-1718501126

See: Black Hat Python, 2nd Edition: Python Programming for Hackers and Pentesters

Fair Use Source:

Bibliography DevOps DevSecOps-Security-Privacy JavaScript Software Engineering


See: Web Security for Developers: Real Threats, Practical Defense Illustrated Edition

Fair Use Source:



See: Hacking Kubernetes: Threat-Driven Analysis and Defense 1st Edition

See also Kubernetes and Cloud Native

Fair Use Source:


Hacker Culture – Late 20th Century

Return to Timeline of the History of Computers or History

Hacker Culture.

Where Did Hacker Culture Come From?

Builder culture: Model building, Radio controlled airplanes.

Greg Hartrell, Product Leader @ Google. Top Quora Writer.Updated August 27, 2017 · ForbesApple News and Observer · 

How hacker culture originated is an interesting story. Here’s a set of perspectives that I found interesting many years after I realized I was pulled into this culture at a young age.

The origins of hacker culture are most attributed to early computer science departments, specifically MIT, in the 1960s. That said, the MIT Tech Model Railroad Club seems to be ground zero, starting with elaborate efforts to automate model trains, and later moved into tinkering with mainframe computing. Hacker culture emerged from a fusion of intellectual curiosity, counter-culture and a hate-on for any technology that you couldn’t easily get access to or tamper with.

An insight I’ll call out is that the culture of self-repair and openness in products was normal in America prior to early computing… people expected to fix and tinker with cars, appliances and every day things, and if you were a kid, you probably grew up with a parent who tinkered with those every day things all the time. When computing in universities was first introduced, they were expensive mainframe systems. The high cost of early computing meant limited access to a few access terminals and restrictive rules on what you could and couldn’t do with those million dollar systems. Other technologies then emerged (more advanced phone systems for example, later personal computers) that continued a trend of being expensive, inaccessible and off limits to the average person. This rubbed up against the old culture of openness and self-repair.

So, hacker culture was a bit of a protest to the trend to centralize, make everything proprietary and hide the way things worked from people. If you couldn’t repair something, you didn’t really own it. If the way something worked was hidden from you, you ought to be suspicious of creator’s intentions. Most importantly, automation and technology offered (and still offers) so much promise to help improve our lives that everyone should be able to use it. So those who felt that way found like-minded folks to come together and tinker with stuff, understand it deeply and teach others around them how to do it.

Each generation since then has found it’s own “authority” or “centralization movement” to push back against, gain back control and and make the technologies around us more open. Early “phreakers” tampered with opaque phone systems to see how the system that helped us communicate really worked. The personal computing era had people assembling bootleg systems in their garages and homes with spare parts. Modems emerged and spawned fragmented communication networks and bulletin board services (BBSes) for sharing knowledge and socializing. And of course, we saw the emergence of the Internet (and it’s open protocol) and open source software culture (massive collaboration and the culture code sharing and open review).

The book “Hackers – Heroes of the Computer Revolution” (Levy) has the best historical summary of the principles of these early groups, which stands the test of time to this day.

I would paraphrase and summarize them this way:

  • Access to computers and anything that may teach you how the world works should be unlimited and total (a.k.a. The hands-on imperative.)
  • All information should be free (later elaborated on as all information also wants to be expensive.)
  • Mistrust authority and promote decentralization, closed systems and bureaucracies are anti-patterns.
  • You should be judged only by your abilities and skill, not “bogus criteria” like demographic traits.
  • You can create art and beauty on a computer. (i.e. computing isn’t purely mechanical in nature… it sits next to the other methods of creativity that we enjoy as humans. Indeed simple code that does great things is akin to a music composition or a poem.)
  • Computers can change your life for the better (i.e. believe in the power of computing to change and enrich people’s lives, and spreading access, and this ethic, can make the world a better place.)

I see a lot of today’s Silicon Valley product development culture continues in these traditions. We have only begun to harness the power of computing to change our lives for the better, and I think we’ll do so through open systems, radical inclusiveness and spreading our knowledge to the many.”

“Mondo 2000 and Wired were instrumental in moving technology to the lifestyle of young college-educated people. They served, and helped grow, the hacker culture created in the 1980s. Hacker conferences multiplied, notably Defcon, started in Las Vegas in 1993 by Jeff Moss, and HOPE (Hackers on Planet Earth), founded in New York in 1994 by the hacker magazine 2600.”

Fair Use Sources:


DevSecOps-Security-Privacy Software Engineering

Bug Bounty Hunter – Freelance Penetration Tester

Bug bounty hunter: “A freelance penetration tester. Often, large companies will create “responsible disclosure programs” that award cash prizes for reporting security holes. Some bug bounty hunters work full time, but often these are full-time professionals who participate outside of work for extra money.” (B085FW7J86)

Fair Use Sources:


DevSecOps-Security-Privacy Software Engineering

Grey Hat Hacker

Grey Hat Hacker – “A hacker somewhere in between white hat and black hat; occasionally these hackers will violate laws such as attempting to break into applications without permission, but often for the sake of discovery or recognition rather than profit or to cause chaos.” (B085FW7J86)

Fair Use Sources:


DevSecOps-Security-Privacy Software Engineering

Black Hat Hacker

Black Hat Hacker – “The archetypal hacker — one who uses hacking techniques to break into systems in order to profit, cause chaos, or to satisfy their own goals and interests.” (B085FW7J86)

Fair Use Sources:


DevSecOps-Security-Privacy Software Engineering

White Hat – Ethical Hacker

White hat

“Sometimes called an “ethical hacker” — one who uses hacking techniques to assist organizations in improving security.” (B085FW7J86)

Fair Use Sources:


DevSecOps-Security-Privacy Software Engineering


Hacker: “Someone who breaks into systems, typically in order to exfiltrate data or cause the system to perform in a way its developers did not originally intend.” (B085FW7J86)

See also: Hacker culture

Fair Use Sources:


Bibliography Cloud DevSecOps-Security-Privacy JavaScript Software Engineering

Web Application Security – Exploitation and Countermeasures for Modern Web Applications

Return to Timeline of the History of Computers

Fair Use Source: B085FW7J86

By Andrew Hoffman

While many resources for network and IT security are available, detailed knowledge regarding modern web application security has been lacking—until now. This practical guide provides both offensive and defensive security concepts that software engineers can easily learn and apply.

Andrew Hoffman, a senior security engineer at Salesforce, introduces three pillars of web application security: recon, offense, and defense. You’ll learn methods for effectively researching and analyzing modern web applications—including those you don’t have direct access to. You’ll also learn how to break into web applications using the latest hacking techniques. Finally, you’ll learn how to develop mitigations for use in your own web applications to protect against hackers.

  • Explore common vulnerabilities plaguing today’s web applications
  • Learn essential hacking techniques attackers use to exploit applications
  • Map and document web applications for which you don’t have direct access
  • Develop and deploy customized exploits that can bypass common defenses
  • Develop and deploy mitigations to protect your applications against hackers
  • Integrate secure coding best practices into your development lifecycle
  • Get practical tips to help you improve the overall security of your web applications

From the Preface

Web Application Security walks you through a number of techniques used by talented hackers and bug bounty hunters to break into applications, then teaches you the techniques and processes you can implement in your own software to protect against such hackers.

This book is designed to be read from cover to cover, but can also be used as an on-demand reference for particular types of recon techniques, attacks, and defenses against attacks. Ultimately, this book is written to aid the reader in becoming better at web application security in a way that is practical, hands-on, and follows a logical progression such that no significant prior security experience is required.

Prerequisite Knowledge and Learning Goals

This is a book that will not only aid you in learning how to defend your web application against hackers, but will also walk you through the steps hackers take in order to investigate and break into a web application. Throughout this book we will discuss many techniques that hackers are using today to break into web applications hosted by corporations, governments, and occasionally even hobbyists. Following sufficient investigation into the previously mentioned techniques, we begin a discussion on how to secure web applications against these hackers.

In doing so you will discover brand new ways of thinking about application architecture. You will also learn how to integrate security best practices into an engineering organization. Finally, we will evaluate a number of techniques for defending against the most common and dangerous types of attacks that occur against web applications today.

After completing Web Application Security you will have the required knowledge to perform recon techniques against applications you do not have code-level access to. You will also be able to identify threat vectors and vulnerabilities in web applications, and craft payloads designed to compromise application data, interrupt execution flow, or interfere with the intended function of a web application. With these skills in hand, and the knowledge gained from the final section on securing web applications, you will be able to identify risky areas of a web application’s codebase and understand how to write code to defend against attacks that would otherwise leave your application and its users at risk.

Suggested Background

The potential audience for this book is quite broad, but the style in which the book is written and how the examples are structured should make it ideal for anyone with an intermediary-level background in software engineering.

Minimum Required Skills

In this book, an “intermediary-level background in software engineering” implies the following:

  • You can write basic CRUD (create, read, update, delete) programs in at least one programming language.
  • You can write code that runs on a server somewhere (such as backend code).
  • You can write at least some code that runs in a browser (frontend code, usually JavaScript).
  • You know what HTTP is, and can make, or at least read, GET/POST calls over HTTP in some language or framework.
  • You can write, or at least read and understand, applications that make use of both server-side and client-side code, and communicate between the two over HTTP.
  • You are familiar with at least one popular database (MySql, MongoDB, etc.).

These skills represent the minimum criteria for successfully following the examples in this book. Any experience you have beyond these bullet points is a plus and will make this book that much easier for you to consume and derive educational value from.

About the Author

Andrew Hoffman is a senior product security engineer at, where he is responsible for the security of multiple JavaScript, NodeJS, and OSS teams. His expertise is in deep DOM and JavaScript security vulnerabilities. He has worked with every major browser vendor, as well as with TC39 and WHATWG ? the organizations responsible for the upcoming version of JavaScript and the browser DOM spec.
Prior to this role, Andrew was a software security engineer working on Locker Service, the world’s first JavaScript namespace isolation library that operates from the interpreter level up. In parallel, Andrew also contributed to the upcoming JavaScript language security feature “Realms,” which provides language level namespace isolation to JavaScript.

Product details:

  • Publication date : March 2, 2020
  • Print length : 331 pages
  • Publisher : O’Reilly Media; 1st edition (March 2, 2020)
  • ASIN : B085FW7J86

Who Benefits Most from Reading This Book?

Prerequisite skills aside, I believe it is important to clarify who will benefit from this book the most, so I’d like to explain who my target audience is. To do so I have structured this section in terms of learning goals and professional interests. If you don’t fit into one of the following categories, you can still learn many valuable or at least interesting concepts from this book.

This book was written to stand the test of time, so if you decide later on to pursue one of the occupations in its target audience, all of the knowledge from this book should still be relevant.

Software Engineers and Web Application Developers

I believe it would be fair to say that the primary audience for this book is an early- to mid-career software engineer or web application developer. Ideally, this reader is interested in gaining a deep understanding of either offensive techniques used by hackers, or defensive techniques used by security engineers to defend against hackers.

Often the titles “web application developer” and “software engineer” are interchangeable, which might lead to a bit of confusion considering I use both of them throughout the upcoming chapters. Let’s start off with some clarification.

Software engineers

In my mind, and for the sake of clarity, when I use the term “software engineer,” I am referring to a generalist who is capable of writing software that runs on a variety of platforms. Software engineers will benefit from this book in several ways.

First off, much of the knowledge contained in this book is transferable with minimal effort to software that does not run on the web. It is also transferable to other types of networked applications, with native mobile applications being the first that come to mind.

Furthermore, several exploits discussed in this book take advantage of server-side integrations involving communication with a web application and another software component. As a result, it is safe to consider any software that interfaces with a web application as a potential threat vector (databases, CRM, accounting, logging tools, etc.).

Web application developers

On the other hand, a “web application developer” by my definition is someone who is highly specialized in writing software that runs on the web. They are often further subdivided into frontend, backend, and full stack developers.

Historically, many attacks against web applications have targeted server-side vulnerabilities. As a result I believe this book’s use case for a backend or full stack developer is very transparent and easily understood.

I also believe this book should be valuable for other types of web application developers, including those who do not write code that runs on a server but instead runs on a web browser (frontend/JavaScript developers).

As I explain in the upcoming chapters, many of the ways in which hackers take advantage of today’s web applications originate via malicious code running in the browser. Some hackers are even taking advantage of the browser DOM or CSS stylesheets in order to attack an application’s users.

These points suggest that it is also important for frontend developers who do not write server-side code to be aware of the security risks their code may expose and how to mitigate those risks.

General Learning Goals

This book should be a fantastic resource for any of the preceding looking to make a career change to a more security-oriented role. It will also be valuable for those looking to learn how to beef up the defenses in their own code or in the code maintained by their organization.

If you want to defend your application against very specific exploits, this book is also for you. This book follows a unique structure, which should enable you to use it as a security reference without ever having to read any of the chapters that involve hacking. That is, of course, if that is your only goal in purchasing this book.

I would suggest reading from cover to cover for the best learning experience, but if you are looking only for a reference on securing against specific types of hacks, just flip the book halfway open and get started reading.

Security Engineers, Pen Testers, and Bug Bounty Hunters

As a result of how this book is structured, it can also be used as a resource for penetration testing, bug bounty hunting, and any other type of application-level security work. If this type of work is relevant or interesting to you, then you may find the first half of the book more to your liking.

This book will take a deep dive into how exploits work from both a code level and an architectural level rather than simply executing well-known open source software (OSS) scripts or making use of paid security automation software. Because of this there is a second audience for this book — software security engineers, IT security engineers, network security engineers, penetration testers, and bug bounty hunters.


Want to make a little bit of extra money on the side while developing your hacking skills? Read this book and then sign up for one of the bug bounty programs noted in Part III. This is a great way to help other companies improve the security of their products while developing your hacking skills and making some additional cash.

This book will be very beneficial to existing security professionals who understand conceptually how many attacks work but would like a deep dive into the systems and code behind a tool or script.

In today’s security world, it is commonplace for penetration testers to operate using a wide array of prebuilt exploit scripts. This has led to the creation of many paid and open source tools that automate classic attacks, and attacks that can be easily run without deep knowledge regarding the architecture of an application or the logic within a particular block of code.

The exploits and countermeasures contained within this book are presented without the use of any specialized tools. Instead, we will rely on our own scripts, network requests, and the tooling that comes standard in Unix-based operating systems, as well as the standard tooling present in the three major web browsers (Chrome, Firefox, and Edge).

This is not to take away from the value of specialized security tools. In fact, I think that many of them are exceptional and make delivering professional, high-quality penetration tests much easier!

Instead, the reason this book does not contain the use of specialized security tools is so that we can focus on the most important parts of finding a vulnerability, developing an exploit, prioritizing data to compromise, and making sure you can defend against all of the above. As a result, I believe that by the end of this book you will be prepared to go out into the wild and find new types of vulnerabilities, develop exploits against systems that have never been exploited before, and harden the most complex systems against the most persistent attackers.

How Is This Book Organized?

You will soon find that this book is structured quite differently than most other technology books out there. This is intentional. This book is purposefully structured so that there is a nearly 1:1 ratio of chapters regarding hacking (offense) and security (defense).

After beginning our adventure with a bit of a history lesson and some exploration into the technology, tools, and exploits of the past, we will move on to our main topic: exploitation and countermeasures for modern web applications. Hence the subtitle of this book.

The main content in this book is structured into three major parts, with each part containing many individual chapters covering a wide array of topics. Ideally, you will venture through this book in a linear fashion, from page one all the way to the final page. Reading this book in that order will provide the greatest learning possible. As mentioned earlier, this book can also be used as either a hacking reference or a security engineering reference by focusing on the first or second half, respectively.

By now you should understand how to navigate the book, so let’s go over the three main parts of this book so we can grasp the importance of each.


The first part of this book is “Recon,” where we evaluate ways to gain information regarding a web application without necessarily trying to hack it.

In “Recon,” we discuss a number of important technologies and concepts that are essential to master if you wish to become a hacker. These topics will also be important to anyone looking to lock down an existing application, because the information exposed by many of these techniques can be mitigated with appropriate planning.

I have had the opportunity to work with what I believe to be some of the best penetration testers and bug bounty hunters in the world. Through my conversations with them and my analysis of how they do their work, I’ve come to realize this topic is much more important than many other books make it out to be.

Why is recon important?

I would go so far as to say that for many of the top bug bounty hunters in the world, expert-level reconnaissance ability is what differentiates these “great” hackers from simply “good” hackers.

In other words, it’s one thing to have a fast car (in this case, perhaps knowing how to build exploits), but without knowing the most efficient route to the finish line, you may not win the race. A slower car could make it to the finish line in less time than a fast one if a more efficient path is taken.

If fantasy-based analogies hit closer to home, you could think of recon skills as something akin to a rogue in an RPG. In our case, the rogue’s job isn’t to do lots of damage, but instead to scout ahead of the group and circle back with intel. It’s the guy who helps line up the shots and figures out which battles will have the greatest rewards.

The last part in particular is exceedingly valuable, because it’s likely many types of attacks could be logged against well-defended targets. This means you might only get one chance to exploit a certain software hole before it is found and closed.

We can safely conclude that the second use of reconnaissance is figuring out how to prioritize your exploits.

If you are interested in a career as a penetration tester or a bug bounty hunter, this part of the book will be of utmost importance to you. This is largely because in the world of bug bounty hunting, and to a lesser extent penetration testing, tests are performed “black box” style. “Black box” testing is a style of testing where the tester has no knowledge of the structure and code within an app, and hence must build their own understanding of the application through careful analysis and investigation.


The second part of this book is “Offense.” Here the focus of the book moves from recon and data gathering to analyzing code and network requests. Then with this knowledge we will attempt to take advantage of insecurely written or improperly configured web applications.


A number of chapters in this book explain actual hacking techniques used by malicious black hat hackers in the real world. It is imperative that if you are testing techniques found in this book, you do so only against an application that you own or have explicit written permission to test exploits against.

Improper usage of the hacking techniques presented in this book could result in fines, jail time, etc., depending on your country’s laws on hacking activity.

In Part II, we learn how to both build and deploy exploits. These exploits are designed to steal data or forcibly change the behavior of an application.

This part of the book builds on the knowledge from Part I, “Recon.” Using our previously acquired reconnaissance skills in conjunction with newly acquired hacking skills, we will begin taking over and attacking demo web applications.

Part II is organized on an exploit-by-exploit basis. Each chapter explains in detail a different type of exploit.

These chapters start with an explanation of the exploit itself so you can understand how it works mechanically. Then we discuss how to search for vulnerabilities where this exploit can be applied. Finally, we craft a payload specific to the demo application we are exploiting. We then deploy the payload, and observe the results.

Vulnerabilities considered in depth

Cross-Site Scripting (XSS), one of the first exploits we dig into, is a type of attack that works against a wide array of web applications, but can be applied to other applications as well (e.g., mobile apps, flash/ActionScript games, etc.). This particular attack involves writing some malicious code on your own machine, then taking advantage of poor filtration mechanisms in an app that will allow your script to execute on another user’s machine.

When we discuss an exploit like an XSS attack, we will start with a vulnerable app. This demo app will be straightforward and to the point, ideally just a few paragraphs of code. From this foundation, we will write a block of code to be injected as a payload into the demo app, which will then take advantage of a hypothetical user on the other side.

Sounds simple doesn’t it? And it should be. Without any defenses, most software systems are easy to break into. As a result, with an exploit like XSS where there are many defenses, we will progressively dig deeper and deeper into the specifics of writing and deploying an attack.

We will initially attempt to break down routine defenses and eventually move on to bypassing more advanced defense mechanisms. Remember, just because someone built a wall to defend their codebase doesn’t mean you can’t go over it or underneath it. This is where we will get to use some creativity and find some unique and interesting solutions.

Part II is important because understanding the mindset of a hacker is often vital for architecting secure codebases. It is exceptionally important for any reader interested in hacking, penetration testing, or bug bounty hunting.


The third and final part of this book, “Defense,” is about securing your own code against hackers. In Part III, we go back and look at every type of exploit we covered in Part II and attempt to consider them again with a completely opposite viewpoint. This time, we will not be concentrating on breaking into software systems, but instead attempting to prevent or mitigate the probability that a hacker could break into our systems.

In Part III you will learn how to protect against specific exploits from Part II, in addition to learning general protections that will secure your codebase against a wide variety of attacks. These general protections range from “secure by default” engineering methodologies, to secure coding best practices that can be enforced easily by an engineering team using tests and other simple automated tooling (such as a linter).

Beyond learning how to write more secure code, you will also learn a number of increasingly valuable tricks for catching hackers in the act and improving your organization’s attitude toward software security.

Most chapters in Part III restructured somewhat akin to the hacking chapters in Part II. We begin with an overview of the technology and skills required as we begin preparing a defense against a specific type of attack.

Initially we will prepare a basic-level defense, which should help mitigate attacks but may not always fend off the most persistent hackers. Finally, we will improve our defenses to the point where most, if not all, hacking attempts will be stopped.

At this point, the structure of Part III begins to differ from that of Part II as we discuss trade-offs that result from improving application security. Generally speaking, all measures of improving security will have some type of trade-off outside of security. It may not be your place to make suggestions on what level of risk should be accepted at the cost of your product, but you should be aware of the trade-offs being made.

Often, these trade-offs come in the form of application performance. The more efforts you take to read and sanitize data, the more operations are performed outside of the standard functionality of your application. Hence a secure feature typically requires more computing resources than an insecure feature.

With further operations also comes more code, which means more maintenance, tests, and engineering time. This development overhead to security often comes in the form of logging or monitoring overhead as well.

Finally, some security precautions will come at the cost of reduced usability.

Trade-off evaluation

A very simple example of this process of comparing security benefits to their cost, in terms of usability and performance, is a login form. If an error message for an invalid username is displayed to the user when attempting to log in, it becomes significantly easier for a hacker to brute force username/password combinations. This occurs because the hacker no longer has to find a list of active login usernames, as the application will confirm a user account. The hacker simply needs to successfully brute force a few usernames, which can be confirmed and logged for later break-in attempts.

Next, the hacker only needs to brute force passwords rather than username/password combinations, which implies significantly decreased mathematical complexity and takes much less time and resources.

Furthermore, if the application uses an email and password scheme for login rather than a username and password scheme, then we have another problem. A hacker can use this login form to find valid email addresses that can be sold for marketing or spam purposes. Even if precautions are taken to prevent brute forcing, carefully crafted inputs (e.g.,,, can allow the hacker to reverse engineer the schema used for company email accounts and pinpoint the valid accounts of execs for sales or individuals with important access criteria for phishing.

As a result, it is often considered best practice to provide more generic error messages to the user. Of course, this change conflicts with the user experience because more specific error messages are definitely ideal for the usability of your application.

This is a great example of a trade-off that can be made for improved application security, but at the cost of reduced usability. This should give you an idea of the type of trade-offs that are discussed in Part III of this book.

This part of the book is extremely important for any security engineer who wants to beef up their skills, or any software engineer looking at transitioning to a security engineering role. The information presented here will help in architecting and writing more secure applications.

As in Part II, understanding how an application’s security can be improved is a valuable asset for any type of hacker. This is because while routine defenses can often be easily bypassed, more complex defenses require deeper understanding and knowledge to bypass. This is further evidence as to why I suggest reading the book from start to finish.

Although some parts of this book may give you more valuable learning than others, depending on your goals, I doubt any of it will be wasted. Cross-training of this sort is particularly valuable, as each part of the book is just another perspective on the same puzzle.

Artificial Intelligence History

WarGames Movie – 1983 AD

Return to Timeline of the History of Computers



Lawrence Lasker (b. 1949), Walter F. Parkes (b. 1951), John Badham (b. 1939)

WarGames was the movie that transformed the computer nerd into a hero. A blockbuster starring Matthew Broderick and Ally Sheedy, the movie follows high school hacking whiz David Lightman, who almost starts World War III between the United States and the Soviet Union when he breaks into a military supercomputer and challenges it to a game of Global Thermonuclear War.

During an online troll for free video games, David unwittingly breaks into a North American Air Defense (NORAD) system that controls the entire US nuclear arsenal (using a back door left by the original programmer, of course). Believing he has found a way to sneak through the back door of a toy company’s network, he challenges the computer to play a game that can be “won” only by not playing at all. Only after targeting Las Vegas and Seattle with Soviet missiles does David realize the game is real and the computer he is playing against has taken matters into its own hands as it escalates the crisis in an attempt to “win” the game.

The movie left such an impression on President Ronald Reagan that he asked the chairman of the Joint Chiefs of Staff, General John W. Vessey Jr., if it really was possible to break into sensitive US government computers. After investigating the plausibility of such a scenario, the general came back with his answer: “Mr. President, the problem is much worse than you think.” Not long after that, US lawmakers published the Computers at Risk report, which established the beginning of the US defensive computer security program.

Written by Lawrence Lasker and Walter Parkes, and directed by John Badham, WarGames left an impact on generations of future coders, many of whom went on to work in Silicon Valley—where, in 2008, Google held a 25th-anniversary screening. The movie’s legacy has lived on with computer hackers as well—for example, the name of the famous Las Vegas hackers’ convention DEFCON is an homage to the film.

SEE ALSO SAGE Computer Operational (1958)

Poster from the movie WarGames, written by Lawrence Lasker and Walter Parkes, and directed by John Badham.

Fair Use Source: B07C2NQSPV