The short answer is “it depends”. What make of laptop (specifically, what chipset) determines how big an issue we’re talking. Also, what’s your threat model matters.
If you lose your laptop, the bios doesn’t really matter, as you can assume the attacker has time to physically remove the hard drive. At that point, you’re counting on whatever drive encryption (or file encryption) you have. The more troubling situation is the “evil maid” attack, where someone has 30-60s of physical access to your machine, can they break in without leaving a trace? With Intel machines, the answer is probably; at least some machines can have malicious code inserted over the ethernet port when the machine first boots. Some machines are more locked down than others (Lenovo Thinkpads, for example, have significant extra security “stuff” included, which makes bypassing the locked bios fairly difficult, even with extended physical access, chip readers, and a soldering iron).
Purism has stripped the Intel Management Engine (IME) of its non-vital components, which probably helps the situation too; I don’t know if anyone has tried to break into one of their machines, but in theory they don’t initialize the network interface preboot.
The situation on AMD is sorta better. The PSP generally doesn’t have access to the NIC, so that avenue of attack is closed from the start. The PSP code is also simple enough that at least one group of independent engineers have dissected the thing and didn’t find anything bad (not finding something != something not being there though). That was for the x370 chipset, I don’t know if anyone has gone to the work of doing the same for the later revisions. On the other hand, it has been demonstrated that an attacker who gains temporary ring-0 access to an AMD system can infect any of several chipsets on the board, which usually requires replacing the motherboard to clean out again.
Anyway, all of the above assumes someone with physical access to the machine. With regard to remote attacks, the risk is quite minimal. There is significant market pressure to deliver performant CPUs, so the odds that silicon space is used for an intentional hardware backdoor is likely slim. The software blob is something of a threat, but the behaviour of the running system needs to be more-or-less as expected (and as mentioned, they can be dissected). On Intel systems, you want to avoid plugging single-nic machines into untrusted wired networks, as in-theory, that opens you up to remote-management exploits, but otherwise you’re probably fine.
Oh, and as a side note, having the firmware open source (but authored by an untrusted company) doesn’t perfectly block this class of attack. If they include undocumented opcodes, those can change the mode of the CPU sufficiently to sneak a backdoor through, even if the source code is readable. That’s not to say having the source code is bad, just that it isn’t a “magic bullet”.