Prática de Shadowing: STOP Running Code On Your Computer - Aprenda a falar inglês com vídeo
Escolha um modo de prática
Cada modo abre uma sala de prática em tela cheia.
173 frases
Se as frases estiverem muito curtas ou longas, clique em Edit para ajustá-las.
1
Every single time you install a dependency, run an extension in your code editor, run the build process for an app you're working on, or run the app itself,
2
you are running code on your computer that you did not write.
3
And that code has access to more than just your project directory.
4
And just as an example, I have this simple Python script here, and I'm running this with no extra privileges.
5
All it does is scan the file system.
6
And with one single command, it has every cookie and session data from Firefox and Chrome,
7
Slack and Discord, as well as access to my NPM token and SSH private keys, basically everything on my machine.
8
So when an attacker's code gets onto your machine, it has access to pretty much everything.
9
And attacker code can come from anywhere.
10
But what we're probably most familiar with is supply chain attacks.
11
Essentially, a package on some public repository gets compromised.
12
And then when end users install that package, they get compromised as well.
13
But it's not as simple as, oh, I don't have any vulnerable dependencies.
14
Why should I care or why does this matter to me, your dependencies have dependencies and your dependencies dependencies have dependencies.
15
These are known as transitive dependencies and it's very possible that even though you're not directly dependent on some vulnerable package,
16
their dependencies might be the victim of some sort of supply chain attack and that's how these things spread.
17
These are real incidents
18
that have increased in their occurrence over the past couple of years as more
19
and more attackers leverage these developer ecosystems
20
that we all thought we could trust the main question isn't really if you'll install something compromised, it's when.
21
And so from there, the question becomes, what can that code do?
22
And that's what we're going to talk about in this video.
23
I'm going to give you a basic primer on security concepts, how running code works, how what it has access to, and how you can limit that access.
24
Because that's really the basic concept that any sort of isolation mechanism or agent container allows us to do, which is prevent the blast radius.
25
If something gets compromised, you want to make sure that it doesn't have access to everything.
26
So let's dive in.
27
My name is CJ.
28
Welcome to Syntax.
29
Now, first, let's talk about the blast radius, which is if something goes wrong, what can it do or what does it have access to?
30
And so if we consider your development machine today, let's say you run all of your projects locally.
31
Everything is happening just directly on your machine.
32
If something gets compromised or goes rogue, it has access to everything on your computer.
33
It has access to your email, it can check if you're logged into your bank, it can access any sort of password vaults, SSH keys, ENV files, essentially anything on your computer
34
an attacker would potentially have access to if you are a victim of their attack.
35
And so the fix is easy.
36
Never run untrusted code on a machine that has anything that you care about.
37
So we're essentially going to shrink that blast radius to zero by isolating code execution from your credentials and accounts.
38
So the answer to this is isolation.
39
When you're running a program, instead of giving it access to your entire computer, we can limit that access.
40
And there are four security concepts you can apply to any one of those isolation levels
41
that we'll talk about in the next section.
42
And the first security concept is the principle of least privilege.
43
Give it only access to what it needs.
44
So maybe your program needs to talk to some hosted database, but will it work with read-only credentials?
45
If so, use those.
46
That way, if those credentials are compromised, they can't write anything to the database.
47
Also, don't run code on the same system
48
that has stored credentials for other services or other unrelated things to the project at hand.
49
Now, number two, the next security concept is network filtering or egress filtering.
50
That is, it can't phone home if it can't make requests.
51
Now, one of the ways attackers take advantage of credential leaks like this are, potentially, if they can run code on your system, they will just send all of the secret data that they found off to some remote computer.
52
And then maybe later, they can go look and try to use those credentials in certain places.
53
But if your code is running in an environment that only has access to specific network resources, like specific servers, specific databases, or specific package manager registries,
54
and not the entire internet, that makes it much harder for an attacker to exfiltrate that data to some remote server or some remote system.
55
Now, number three, our next security concept is ephemeral environments, that is temporary environments.
56
Essentially, we can use the environment, destroy it, and then nothing lingers around.
57
So if there is anything compromised, it's completely gone the moment we delete that isolated system.
58
And number four, the last one is defense in depth.
59
So no single layer of protection is enough.
60
We essentially stack them so we get more security guarantees with these layers of security.
61
So isolation alone isn't going to prevent that one isolated thing from being compromised.
62
We can do these other things like only mount the secrets
63
that it has access to or only give it certain network access to limit
64
that blast radius if that one isolated environment does become compromised.
65
Now, how do we actually do all of this?
66
I'm going to give you five ranks on the ladder of isolation you can choose from.
67
And level one is containers.
68
Now, if you're in the world of development, you've probably heard of Docker and you may not be using it yet, but this is one of the easiest ways to get up and going with an isolated environment.
69
You essentially define a configuration that says what operating system you're running, what dependencies does it have, what steps need to happen in order to set this container up to be ready for your project.
70
And then the container runtime uses that configuration to automatically spin up a brand new environment that has everything ready to go.
71
Now, containerization is operating system level virtualization.
72
Essentially, every container that gets created gets its own set of processes that it can access, its own file system, and its own users.
73
But each these containers shares the host operating system's kernel.
74
So this is a basic level of isolation because if compromised code is able to break out of that container,
75
it immediately has access to the host operating system and in turn would have access to all of your files.
76
Now while container breakouts are rare, they do happen and so there are other levels of isolation that we'll talk about soon.
77
Now related to containers is the dev container specification.
78
Essentially you define a container configuration specific to the development environment that you need for your project,
79
And then there are various code editors like VS Code or Zed that can then look at that configuration, spin up one or more containers, and automatically connect your editor instance to that running container.
80
Then any file changes you make are automatically synced, and any dependencies that got installed or editor extensions that ran or code that ran runs inside the container.
81
Now, this is a great way to share your development configuration with your team
82
and make it really easy for people to get up and going.
83
But like we mentioned, it's running in a container, which isn't necessarily the best type of isolation.
84
So that brings us to level two in our ladder of isolation, virtual machines.
85
Now, virtual machines are hardware level virtualization.
86
Essentially, every virtual machine that gets created has its own hard drive, its own RAM, and its own CPU.
87
And all of that is being shared from the host system.
88
So each virtual machine gets its own dedicated resources.
89
Now, virtual machines are typically more resource intensive and sometimes slower to start up than containers,
90
but they limit our exposure even more because breaking out of a virtual machine is a much harder technical feat.
91
And so if vulnerable code does somehow get onto those virtual machines, it's very unlikely that it'll be able to break out to the host operating system.
92
Now, there are a ton of different ways to get up and going with virtual machines, but one of the easiest ways is to use a program like UTM
93
if you're on macOS or VirtualBox if you're on Windows or Linux.
94
And this is just a GUI application you can use to create virtual machines.
95
Essentially, you can decide how much CPU they get, how much RAM they get.
96
You can then boot them to a specific Linux or Windows installer, and now you have a virtual machine running on your computer.
97
Applications like this are a good entry point, especially if you want to learn about Linux.
98
Even if you're on Windows or Mac OS, you can boot up a Linux virtual machine and then play around with it, and you don't even have to actually have a dedicated Linux machine.
99
Now, using GUI applications like this is a little more cumbersome
100
if you want to set it up for development because they're only scriptable or automatable in certain aspects.
101
And if you want to create reproducible environments, it's a little bit trickier to do with these GUI programs.
102
One of the more automated and scriptable ways of spinning up VMs is actually from Docker and it's called Docker Sandbox.
103
And it actually doesn't use containers.
104
It uses what is known as micro VMs.
105
And with one command, Docker Sandbox will spin up a virtual machine
106
that is linked to that one project directory that you're running the command in.
107
It has no access to other files on your system.
108
And Docker Sandbox takes that same configuration file that you would use with Docker containers.
109
So this is much easier to set up if if you want more reproducible dev environments for your sandboxes.
110
Now, another tool I came across is called Lima, and it essentially manages virtual machines for you, but from the command line.
111
And there's also a tool called CoLima, which only works on Mac OS and Linux, but it's essentially a wrapper on top of Lima that makes it
112
so that you can use your existing Docker configuration files to spin up virtual machines with Lima.
113
Now let's move on to level three of separation, full separation.
114
Essentially, you have an entirely separate machine for your development workflows.
115
Now, you could go fully custom and rent a VPS or virtual private server, or even rent a dedicated machine from some cloud hosting service, and then set up that machine as your development machine.
116
And then anytime you need to do development work, you SSH into that machine.
117
And that means if that machine ever gets compromised, it's not your computer, all of it is in the cloud.
118
Now, just like all the levels of security that we talked about, if you have a big single dedicated development machine in the cloud, you're not necessarily isolating your projects from each other.
119
And so if you have multiple projects with multiple credentials, you're not really adhering to the principle of least privilege for all of the apps
120
that are running on that development machine in the cloud.
121
So in theory, you could actually combine this with level two separation, where you actually spin up virtual machines on that machine you have in the cloud.
122
And then you basically have three levels of separation between you and the machine that that code is actually running on.
123
Now, you could also go the more opinionated route and use something like GitHub Codespaces.
124
You can essentially spin up a Codespace for any one of your projects on GitHub.
125
And this gives you a machine running in the cloud that only has access to that one project.
126
There are also self-hosted alternatives like coder.com, and you can essentially run this on your own VPS, but you get a more streamlined interface where you can define what type of environment each project needs
127
that you need to spin up and
128
that brings us to level four on the ladder of isolation
129
which i'll label as paranoid which is potentially justified
130
and these scenarios all try to add as much separation between your computer with all of your secrets
131
and everything you care about and the actual running code.
132
And the first is just a separate laptop.
133
Some of us potentially have old laptops we're not using anymore.
134
And you might be surprised how performant some of these custom Linux distributions have gotten in terms of older hardware.
135
And so I actually have one of these in my home lab.
136
It's just an old ThinkPad running CacheOS, and I use it as a development machine.
137
So it's totally separate from my computer, but it's in my house.
138
It's not even in the cloud.
139
And so I'm able to run all of my development workflows that I need, even on some of the older specs.
140
And to get even more paranoid than that, you might actually use a live operating system.
141
So this is used a lot by hackers or people
142
that don't want to have any trace of anything they've done on a computer.
143
They essentially use a live operating system like Tails OS, or you could even boot into a live USB that has Ubuntu on it, and you do all of your development work there.
144
And then the moment you shut down that laptop, it doesn't save anything because it was just running in that live USB environment.
145
Now, this seems like a really cumbersome way to do some development in my opinion, but it's also totally possible to do.
146
And because these are essentially ephemeral boots, every time you boot up, it's a brand new, fresh operating system.
147
You don't have any secrets or anything that could be extracted by malicious code.
148
And finally, this is hardcore tenfoil hat mode.
149
You could use an air-gapped machine.
150
That is, go into a room, unplug the literal Wi-Fi board from your laptop, and do all of your development work there.
151
And that way, if anything is compromised, it can't exfiltrate that data anywhere because there's no way for it to actually reach the internet.
152
Now, there could be some secret spy device nearby that's actually listening to the sound
153
that your hard drive is making or the sound that your keyboard makes when you're typing.
154
And it could exfiltrate all of that data somewhere else, but we're not going to go there.
155
So these are the five levels of isolation.
156
And if you really want to prevent yourself from being the victim of the next supply chain attack, you should be doing at least level one, if not level two.
157
And combine these levels with the security concepts that we covered at the beginning, including the principle of least privilege.
158
That is, give these isolated environments only access to the credentials that they need and nothing more.
159
And every one of those levels of isolation I talked about has some sort of mechanism for only mounting
160
or sharing a specific directory or specific files and not sharing your entire host file system.
161
And with that, you should also do egress filtering.
162
That is, limit the network resources that any one of these isolated environments has access to.
163
Because if they do get compromised, they potentially won't be able to reach out to an attacker server or exfiltrate your data to an attacker's remote host. And
164
And every one of these isolation mechanisms supports firewalls
165
or operating system level network blocks
166
that can essentially lock down these isolated environments to only have access to the network resources that they need access to.
167
And of course, to bring it all together, defense in depth.
168
Combine all of these various security mechanisms with an isolation mechanism to reduce your overall blast radius if you do become compromised.
169
So that's all I got for you in this one.
170
If you're using any of the tools I mentioned or have suggestions for other tools that people could use, let us know down in the comments.
171
And if you have any questions about setting any of this stuff up, let us know in the comments as well.
172
All right, stay safe out there.
173
I'll see you in the next one.
Baixar aplicativo
Tudo o que você precisa para falar fluentemente
Pronúncia com IANota em cada frase
Prática de IPADomine cada som
VocabulárioMonte seu banco de palavras
Jogo de vocabulárioAprenda brincando
📺 Mesmo canal
C14
Can This Robot Be My Personal Assistant
Daily ConversationWorking Adults
C14
8 Tech Choices to Lock In Before Agentmaxxing
Daily ConversationWorking Adults
C13
8 New CSS, JS and HTML Features You Should Know
Daily ConversationWorking Adults
C11
I bought Black Market AI Tokens on Chinese Amazon
Daily ConversationWorking Adults
C13
AI Is Stealing From You
Daily ConversationUniversity StudentsWorking Adults
✨ Vídeo recomendado
C11
158 frases
OWASP Top 10 Explained
Daily ConversationUniversity StudentsWorking Adults
C11
68 frases
GitHub Copilot now controls your command line...
Daily ConversationUniversity StudentsWorking Adults
C11
180 frases
Armchair Architects: Resiliency in the Cloud – Core Patterns
Daily ConversationUniversity StudentsWorking Adults
C11
40 frases
The Engineering that Runs the Digital World 🛠️⚙️💻 How do CPUs Work?
Daily ConversationUniversity StudentsWorking Adults
C12
162 frases
Crypto Agility Explained: Protect Data from Quantum Computing Threats
Daily ConversationUniversity StudentsWorking Adults
C11
146 frases
🚫 Java Deadlock Explained: Why Your Code is Stuck 😱 (Beginners Must Watch!)
Daily ConversationUniversity StudentsWorking Adults
C11
215 frases
Creator of C# and TypeScript: "AI will NEVER Replace Coders, Here's Why" | Anders Hejlsberg
Daily ConversationUniversity StudentsWorking Adults
B22
8 frases
Every Cybersecurity Beginner Should Watch This First (Networking Fundamentals)
Daily ConversationUniversity StudentsWorking Adults
C16
51 frases
Linux got wrecked by backdoor attack
American AccentDaily ConversationUniversity StudentsWorking Adults
C11
78 frases
How I deploy serverless containers for free
Daily ConversationUniversity StudentsWorking Adults
C11
78 frases
The easy way to keep your repos tidy.
Daily ConversationUniversity StudentsWorking Adults
C11
54 frases
Traceroute: You're Probably Reading the Results Wrong
Daily ConversationUniversity StudentsWorking Adults
Vocabulário e dicas de fala para esta lição
Este vídeo tem 173 frases e 2795 palavras para praticar shadowing. A fala dura 13:18. O falante fala rápido, cerca de 210 palavras por minuto, então espere sons ligados e reduzidos. 82% das palavras estão entre as 3.000 mais comuns do inglês; vale a pena estudar o restante antes de começar.
Vocabulário principal deste vídeo
15 palavras do vídeo que vale a pena aprender, com pronúncia e significado:
| Palavra | Pronúncia | Significado |
|---|---|---|
| essentially advérbio | /ɪˈsɛnʃəli/ | em essência, essencialmente |
| container substantivo | /kənˈteɪ.nəɹ/ | recipiente |
| virtual adjetivo | /ˈvɜɹt͡ʃuəl/ | virtual |
| compromise substantivo | /ˈkɑmpɹəˌmaɪz/ | meio-termo, acordo |
| isolation substantivo | /ˌaɪsəˈleɪʃən/ | isolamento, isolação |
| isolate verbo | /ˈaɪ.sə.leɪt/ | isolar |
| spin verbo | /spɪn/ | girar, rodar |
| cloud substantivo | /ˈklaʊ̯d/ | nuvem, nimbo |
| configuration substantivo | /kənˌfɪɡ.əˈɹeɪ̯.ʃən/ | configuração |
| attacker substantivo | /əˈtækɚ/ | agressor, atacador |
| potentially advérbio | /pəˈtɛnʃ(ə)li/ | potencialmente |
| blast substantivo | /blæst/ | ventania |
| mechanism substantivo | /ˈmɛk.ə.nɪ.zəm/ | mecanismo |
| boot substantivo | /but/ | bota |
| separation substantivo | /ˌsɛp.əˈɹeɪ.ʃən/ | separação |
Phrasal verbs que você vai ouvir
| Palavra | Pronúncia | Significado |
|---|---|---|
| get up verbo | subir | |
| set up verbo | /ˌsɛt ˈʌp/ | preparar |
| lock down verbo | confinar | |
| shut down verbo | apagar, encerrar |
Gramática neste vídeo
As estruturas que o falante mais usa, com as palavras exatas do vídeo:
| Estrutura | No vídeo |
|---|---|
| Voz passiva be + particípio passado — o foco está no que acontece, não em quem faz | are known · are compromised · being compromised |
| Present perfect have/has + particípio passado — uma ação passada que ainda importa agora | have increased · has stored · you've probably heard |
| Orações relativas who / which + oração — informação extra sobre uma pessoa ou coisa | radius, which is · paranoid which is |
Pronúncia para ficar de olho
O falante usa 48 contrações e formas reduzidas, como you're, don't, we're. Diga-as na forma curta, do jeito que você ouve.
- Os sons de “sh” e “zh”: essentially /ɪˈsɛnʃəli/, isolation /ˌaɪsəˈleɪʃən/, configuration /kənˌfɪɡ.əˈɹeɪ̯.ʃən/, potentially /pəˈtɛnʃ(ə)li/, separation /ˌsɛp.əˈɹeɪ.ʃən/
- Palavras longas — acerte a sílaba tônica: essentially /ɪˈsɛnʃəli/, isolation /ˌaɪsəˈleɪʃən/, dependency /dɪˈpɛndənsi/, configuration /kənˌfɪɡ.əˈɹeɪ̯.ʃən/, potentially /pəˈtɛnʃ(ə)li/
Como praticar com este vídeo
- Ouça o vídeo inteiro uma vez sem falar e anote as palavras que você não conhece.
- Comece na velocidade 0,75×, faça shadowing frase por frase e volte à velocidade normal quando ficar fácil.
- Grave a sua voz e compare com o original, prestando atenção a palavras como essentially, container, virtual.
O que é a Técnica de Shadowing?
Shadowing é uma técnica de aprendizado de idiomas com base científica, originalmente desenvolvida para o treinamento de intérpretes profissionais. O método é simples, mas poderoso: você ouve áudio em inglês nativo e repete imediatamente em voz alta — como uma sombra seguindo o falante com 1-2 segundos de atraso. Pesquisas mostram melhora significativa na precisão da pronúncia, entonação, ritmo, sons conectados, compreensão auditiva e fluência na fala.