Every serious application, regardless of their resume, got a 30-45 minute phone call. You post hiring posts all over the place and you get a lot of unserious submissions, but an easy way to screen them out is to respond with a question, like, "Thanks for writing! We'd be happy to talk to you. Can we ask what has you interested in doing software security?" The answer doesn't matter, as long as there is an answer.

I did a lot of calls where I knew a couple minutes in that we were unlikely to hire the person, but (a) I got surprised by outcomes enough not to shirk on those calls, and (b) those calls are a very small price to pay for finding buried talent.

I also advocate for a work sample based hiring pipeline and the plagiarism question often comes up. My response is always:

1) People generally don't cheat. If you have a high percentage of cheaters its how you are filling your pipeline you need to address, not the filter.

2) What most people think of as "plagiarism" is actually very common in the real work of software developers. Very frequently you see/mimic other peoples work to solve problems. Instead of being freaked out about a skill that is central to the job, why not use it to evaluate the candidate. Did they "plagiarize" the right thing? Did they do it effectively. Did they do something backwards that a simple google search would have found a thing to copy?

3) If you are big enough for plagiarism to be a real problem and have addressed points 1 & 2, it is relatively easy to detect mechanically (and there is a surprising amount of research in the field as CS professors invariably write both an automated grader and then an automated cheater detector).