Backend Security Pitfalls: Auth, Secrets, Supply Chain, and the Power of Defaults

[0:00]Hovhannes: Welcome back to the show! You’re listening to Stack Layers, where we break down the real engineering challenges behind modern backend systems. I’m your host, Jamie Chen. Today we’re looking at a topic that gets plenty of lip service but is still the root of so many outages and incidents: backend security pitfalls—especially around authentication, secrets, supply chain, and those sneaky default settings. Joining me is Morgan Patel, Principal Backend Engineer and application security advocate at SecureStack Solutions. Morgan, welcome to the show!

[0:35]Morgan Patel: Hey Jamie, thanks for having me. This is one of my favorite topics to dig into, so I’m excited.

[2:00]Hovhannes: Let’s set the stage. When people talk about backend security, what do you think is most misunderstood by developers and even some engineering leaders?

[2:25]Morgan Patel: Great question. I think the biggest misunderstanding is assuming that because something is ‘back-end’—behind an API gateway or not directly exposed to users—it’s somehow safe by default. But the reality is, most serious incidents I see come from backend systems where teams assumed they were isolated or trusted, but attackers found a way in, often through overlooked weak points.

[3:15]Hovhannes: That’s so true. The number of times I’ve heard, ‘Oh, that’s an internal-only API, we don’t need to worry as much…’ But attackers love those assumptions.

[3:35]Morgan Patel: Exactly. Internals aren’t as internal as we’d like to think, especially with cloud and microservices. Lateral movement—where an attacker gets into one service and then pivots to others—is very real.

[4:00]Hovhannes: Let’s pause and define that. Lateral movement means once an attacker is in, say, a less-important backend service, they use that access to reach more sensitive parts of the infrastructure, right?

[4:25]Morgan Patel: Right. And because backend services often talk to each other with elevated privileges, a small mistake in one place can have outsized impact.

[5:00]Hovhannes: So the myth is: ‘If it’s not public, it’s not a target.’ In reality, backend systems are juicy targets. Why do you think backend security challenges have grown more complex recently?

[5:40]Morgan Patel: A big reason is system complexity. The sheer number of moving parts—APIs, microservices, job queues, third-party integrations—means the attack surface is huge. Also, teams are moving fast, and security often lags behind feature delivery. Plus, with infrastructure as code and everything being API-driven, misconfigurations are easier to make and harder to spot.

[6:00]Hovhannes: Let’s dive into specifics. How do backend security problems differ from frontend security issues, in your experience?

[6:40]Morgan Patel: Frontend security is often about protecting the user—things like cross-site scripting or clickjacking. With backend, the risks are more about data exposure, privilege escalation, and protecting sensitive operations. If you mess up backend auth or secrets, an attacker can do far more damage than just defacing a page.

[7:10]Hovhannes: So backend vulnerabilities are often silent until something catastrophic happens?

[7:25]Morgan Patel: Exactly. A frontend issue might be visible or annoying, but a backend flaw can mean data theft, ransomware, or total loss of control.

[8:20]Hovhannes: Let’s talk about trust boundaries. You mentioned teams often trust their own internal APIs too much. Can you give an example?

[8:55]Morgan Patel: Sure. I worked with a team that had services only accessible from the VPC, no external ingress. They thought, ‘We don’t need strict auth between services.’ But someone accidentally deployed a debug tool that exposed an internal port to the public internet. Suddenly, their ‘safe’ APIs were reachable to anyone who found the port.

[9:40]Hovhannes: Classic. One tiny mistake and the whole trust model collapses.

[9:50]Morgan Patel: Exactly. And attackers are scanning for these mistakes all the time.

[10:15]Hovhannes: Alright, let’s dig into authentication. Where do backend teams most often slip up with auth?

[10:55]Morgan Patel: A big one is token handling. For example, passing JWTs or session tokens around without validating signature or expiration. Or storing tokens in insecure places. I’ve seen internal APIs that accept any token, without proper verification, because they assume only other trusted services will call them.

[12:00]Hovhannes: That’s a subtle but deadly mistake. Can you share a story where that kind of issue led to a real incident?

[13:20]Morgan Patel: Absolutely. One case: a team used JWTs for service-to-service auth, but their verification logic only checked the token had a valid format, not the signature. An attacker crafted a fake JWT and got access to sensitive endpoints. It took weeks to notice, because logs just showed ‘authorized’ traffic.

[13:45]Hovhannes: That’s terrifying. And I bet the team thought, ‘We’re using JWTs, so we’re secure.’

[14:05]Morgan Patel: Exactly. It’s easy to get a false sense of security just by using certain technologies, but implementation really matters.

[15:05]Hovhannes: Let’s talk about passwords and credential storage. Are teams still making the same old mistakes?

[15:40]Morgan Patel: Unfortunately, yes. I still see plain MD5 or SHA-1 hashes in production, or even plaintext passwords in rare cases. People also forget to use salts, or they use a single global salt, which isn’t enough. And password reset flows can be especially risky if not handled carefully.

[16:25]Hovhannes: If you had to pick just one guideline for secure password storage, what would it be?

[16:50]Morgan Patel: Use a slow, adaptive hash like bcrypt or Argon2, with a unique salt per password. Bonus points for adding versioned hashes so you can upgrade algorithms over time.

[17:30]Hovhannes: Love that. Let’s talk about rolling your own authentication versus using libraries. What’s your take?

[18:00]Morgan Patel: Generally, I’m in favor of using well-maintained libraries for auth. They’ve seen more eyes, more edge cases. But you still need to configure them correctly. I get it—sometimes there’s pressure for custom flows, but that’s almost always where issues creep in.

[18:35]Hovhannes: Is there ever a good case for custom auth logic?

[18:55]Morgan Patel: Maybe if you have a truly unique business requirement. But even then, I’d try to build on top of battle-tested primitives, not from scratch.

[19:20]Hovhannes: Let’s get into secrets. Why are hardcoded secrets still so common, even in mature teams?

[19:55]Morgan Patel: Honestly, it’s mostly about convenience and pressure. It’s easy to stick a key in a config file to get something working. But then it gets checked into version control, and before you know it, it’s in a public repo or shared around in Slack. People underestimate how persistent those leaks are.

[20:25]Hovhannes: What’s the worst secret exposure you’ve seen?

[20:50]Morgan Patel: One time, an AWS access key was committed to a repo, and within minutes, bots were spinning up cryptomining instances on the company’s account. The cost was thousands before they noticed.

[21:10]Hovhannes: That’s wild. So, what are the main options teams have for secrets management?

[21:45]Morgan Patel: The main ones: environment variables, dedicated secrets managers like HashiCorp Vault or AWS Secrets Manager, and encrypted config files. Each has pros and cons. Env vars are easy but can leak if your process crashes or logs are exposed. Vaults are more secure but add operational overhead.

[22:15]Hovhannes: Do you have a preference?

[22:35]Morgan Patel: For anything sensitive in production, I like using a real secrets manager, even if it’s a bit more work. For local dev, env vars are usually fine—as long as you don’t check them in.

[23:00]Hovhannes: How do secrets usually leak, besides being checked into git?

[23:30]Morgan Patel: Logs and crash reports are big culprits. Sometimes secrets are dumped into logs for ‘debugging’ and never removed. Also, CI/CD pipelines often have misconfigured permissions—so secrets end up exposed in build logs or artifacts.

[24:00]Hovhannes: Let’s do a quick case study. Have you seen secrets leak through CI/CD in a real project?

[24:20]Morgan Patel: Absolutely. A team had a script that printed all environment variables for troubleshooting. It ran in CI, and the logs—which included DB passwords and API keys—were stored for months. Anyone with access to the CI system could read them.

[24:45]Hovhannes: Ouch. Let’s pivot to supply chain. What are supply chain vulnerabilities in the context of backend systems?

[25:15]Morgan Patel: It’s all about your dependencies: third-party libraries, frameworks, even container images. Attackers target popular packages, or publish malicious ones with similar names. Once you install that library, you’re running their code in your backend.

[25:35]Hovhannes: How big of a risk is this for backend teams?

[25:55]Morgan Patel: It’s a huge risk. Modern backend stacks have dozens, if not hundreds, of dependencies. A vulnerability in just one can compromise the whole stack. And because of transitive dependencies—libraries depending on other libraries—it’s hard to even know what you’re running.

[26:30]Hovhannes: Can you share a case where a supply chain issue caused real-world impact?

[26:55]Morgan Patel: Definitely. There was a case where a team updated a seemingly harmless logging library. Unbeknownst to them, a new minor version depended on a compromised package, which quietly exfiltrated environment variables. It went unnoticed for weeks, until someone spotted unusual outbound traffic.

[27:15]Hovhannes: Wow. That’s a nightmare. How did they respond?

[27:25]Morgan Patel: First, they rolled back the update and rotated all exposed secrets. Then they set up dependency scanning and reviewed their update process so it couldn’t happen again.

[27:30]Hovhannes: We’re about to hit our break, but when we come back, let’s dive into another culprit: default settings. Why so many teams run insecure defaults in production, and how to spot and fix them. Stick around!

[27:30]Hovhannes: Alright, picking up from where we left off—so we’ve talked a lot about the risks around authentication and secrets. I want to shift gears a bit and dig into the supply chain side. This is one of those areas that’s gotten a lot more attention recently, but I feel like a lot of backend teams still don’t know where to start. What are the most common supply chain pitfalls you see?

[27:57]Morgan Patel: Great question. The biggest pitfall is treating dependencies like they’re always trustworthy, just because they’re popular or widely used. I’ve seen teams pull in huge libraries just for one tiny feature, not realizing that every dependency is another potential attack vector. Another big one is not locking dependency versions or not using tools to check for vulnerabilities in dependencies as part of the CI pipeline.

[28:28]Hovhannes: So basically, 'dependency sprawl' and not tracking what you’re actually running in production?

[28:42]Morgan Patel: Exactly. And it’s not just direct dependencies—transitive dependencies can introduce vulnerabilities too. One example: I worked with a backend team that used a popular package for image processing. They didn’t realize that a sub-dependency had a remote code execution flaw. It sat in production for months until a pentest surfaced it.

[29:12]Hovhannes: Wow. Was that hard to remediate, or did they have something like Dependabot running?

[29:25]Morgan Patel: They didn’t have any automated alerting set up. So the fix involved a scramble—manually auditing the dependency tree, patching, and deploying. They ended up integrating security scanning into their PR process afterward. But they lost a lot of sleep that week.

[29:49]Hovhannes: Sounds stressful. For teams listening, what’s a realistic first step if they don’t have any supply chain security right now?

[30:04]Morgan Patel: Start simple: enable automated dependency scanning in your CI. Most platforms have plugins for this now. Next, use lockfiles—don’t leave versions floating. Then, periodically audit your dependency list and remove anything you’re not using.

[30:28]Hovhannes: Makes sense. Do you have a story where something as basic as a lockfile could have saved the day?

[30:43]Morgan Patel: Absolutely. An e-commerce backend I reviewed once had a sudden production outage. It turned out one of their dependencies updated to a breaking version because they didn’t have a lockfile. That update also introduced a security hole. If they’d used a lockfile, the deployment would have been stable—and secure.

[31:08]Hovhannes: Let’s pivot a bit. Earlier, you mentioned 'safe defaults.' In backend frameworks, what are some unsafe defaults you’ve seen catch teams off guard?

[31:24]Morgan Patel: One classic example: default admin credentials. Some frameworks ship with 'admin:admin' or similar. Another is overly permissive CORS settings, like 'Access-Control-Allow-Origin: *'. There’s also default debug endpoints left enabled in production—those can leak sensitive info.

[31:52]Hovhannes: Do you think teams are aware of these risks, or is it still an afterthought?

[32:04]Morgan Patel: It’s mixed. More teams are aware now, but it’s easy to forget when you’re rushing to ship features. Sometimes, devs don’t realize a debug endpoint is still exposed, or they assume no one will find it. Attackers do look for these things.

[32:27]Hovhannes: Is there a favorite example where a 'safe default' would have prevented a breach?

[32:41]Morgan Patel: Actually, yes. I know of a SaaS company that suffered a data leak because their API returned verbose error messages in production. The default setting was detailed tracebacks. If they’d switched to a safe default—like generic error messages—they’d have avoided exposing internal logic.

[33:04]Hovhannes: That’s a classic. Let’s do a quick rapid-fire round—just say the first thing that comes to mind. Ready?

[33:08]Morgan Patel: Let’s do it.

[33:11]Hovhannes: One thing every backend developer should check in their app today?

[33:14]Morgan Patel: Who can access production secrets.

[33:17]Hovhannes: One dependency you wish people would stop using blindly?

[33:20]Morgan Patel: Anything that handles JWTs without scrutiny.

[33:24]Hovhannes: Most overlooked log source for incident forensics?

[33:26]Morgan Patel: Reverse proxy logs.

[33:29]Hovhannes: Your favorite tool for scanning for secrets in code?

[33:31]Morgan Patel: TruffleHog.

[33:33]Hovhannes: Worst place you’ve seen a secret stored?

[33:36]Morgan Patel: In a public code snippet on Stack Overflow.

[33:39]Hovhannes: Most common mistake in RBAC implementations?

[33:42]Morgan Patel: Assuming roles don’t overlap in privilege.

[33:47]Hovhannes: Awesome. I love those answers. Let’s talk about secrets management a bit more. If you’re advising a team starting from scratch, where should they begin?

[34:03]Morgan Patel: First, never hardcode secrets. Use environment variables or a secrets manager service, like HashiCorp Vault or AWS Secrets Manager. Second, make sure secrets are rotated regularly. Third, restrict who and what can access those secrets, using least privilege.

[34:28]Hovhannes: Let’s say a team is still in the habit of emailing API keys to each other—how do you convince them to change?

[34:44]Morgan Patel: I usually show them real-world breach stories. Sometimes, I’ll even run a demo where I scan their repo and show how easily I can find secrets. Seeing it firsthand is a wake up call. It’s about making the risk tangible.

[35:05]Hovhannes: That’s powerful. Can you share a mini case study about a secrets leak that had downstream impact?

[35:22]Morgan Patel: Sure. There was a fintech startup storing database credentials in a shared Google Doc. One day, an ex-contractor’s account was compromised, and the attacker used those creds to dump their customer data. The team had to rotate everything and notify clients. It was a painful lesson.

[35:47]Hovhannes: Ouch. For teams using cloud providers, is it enough to just rely on built-in secret storage?

[36:03]Morgan Patel: It’s a good start, but not a silver bullet. You still need to enforce access controls, monitor access logs, and make sure secrets aren’t accidentally logged or cached. And don’t forget about backups—sometimes secrets leak through old database dumps.

[36:29]Hovhannes: Let’s talk about incident response. Say a team finds out a secret has leaked—what’s your step-by-step protocol?

[36:44]Morgan Patel: First, revoke and rotate the secret immediately. Second, audit logs to see if it’s been used maliciously. Third, patch any process that leaked it—like removing it from git history. Finally, review your controls to prevent a repeat.

[37:06]Hovhannes: Have you ever seen a team skip that auditing step, and what happened?

[37:19]Morgan Patel: Yes, and it’s risky. One team rotated their AWS keys after a leak but never checked CloudTrail logs. Turns out, someone had spun up crypto miners on their account for weeks. They only caught it when the bill arrived.

[37:44]Hovhannes: Let’s dig into that trade-off: convenience versus security. What do you say to devs who resist stricter controls because it slows them down?

[38:00]Morgan Patel: I get it—security can feel like friction. But a breach is a lot more disruptive. The key is to automate as much as possible: use CI/CD to inject secrets, set up one-click rollbacks, and use role-based access so devs only see what they need.

[38:25]Hovhannes: How do you handle situations where business needs seem to clash with security best practices?

[38:38]Morgan Patel: It’s all about risk management. Sometimes you accept a little risk for speed, but document it and revisit later. Make sure leadership is aware and that there’s a plan to tighten things once the pressure eases.

[39:01]Hovhannes: Let’s switch to another mini case study—maybe something supply chain related?

[39:17]Morgan Patel: Sure. I worked with a SaaS company that unknowingly used a compromised NPM package. The attacker had published a malicious update under the guise of a minor patch. Their CI didn’t pin versions, so the update slipped in and exfiltrated environment variables, including database URLs. They found out only after users reported suspicious activity.

[39:48]Hovhannes: How did they recover from that?

[40:01]Morgan Patel: They froze all deployments, audited every dependency, and rolled new credentials for every service. Then they implemented dependency pinning and set up automated scanning. It was a huge effort, but it rebuilt trust.

[40:23]Hovhannes: Are there any tools or practices you recommend to spot these malicious dependency updates early?

[40:37]Morgan Patel: Yes—use tools like Snyk, OSV-Scanner, or GitHub’s Dependabot. Also, review changelogs before updating any package, and avoid automatic upgrades in CI for production dependencies.

[40:56]Hovhannes: How often do you recommend teams audit their dependencies?

[41:07]Morgan Patel: At least quarterly, but ideally, integrate it into every sprint. Make it part of your release checklist.

[41:23]Hovhannes: Circling back to authentication, are there any less obvious auth pitfalls you see in backend apps?

[41:37]Morgan Patel: Definitely. Things like failing to invalidate tokens after a password change, or not setting token expiration. I’ve also seen issues where session state isn’t cleared after logout, so users can still make API calls.

[41:59]Hovhannes: How would you approach implementing token expiration securely?

[42:12]Morgan Patel: Set short-lived tokens and use refresh tokens with proper revocation. Store tokens securely—never in URLs or local storage if you’re also exposing web interfaces. And monitor for token reuse.

[42:32]Hovhannes: What about multi-factor authentication? Is it overkill for most backend systems?

[42:45]Morgan Patel: Not overkill—especially for admin interfaces or anything touching user data. Even adding an extra approval step for sensitive actions makes a big difference.

[43:03]Hovhannes: Have you seen any creative approaches to enforcing safe defaults?

[43:16]Morgan Patel: One team wrote config validation scripts that run at deployment. If a debug endpoint or a default password is detected, the build fails. It’s a simple but powerful guardrail.

[43:38]Hovhannes: Let’s talk about monitoring. Once a backend app is live, what do you advise teams to watch for security signals?

[43:54]Morgan Patel: Look for anomalies in authentication attempts—failed logins, odd IP addresses, sudden spikes. Also, monitor for new dependencies being introduced, and any changes to your secrets management systems.

[44:16]Hovhannes: Do you recommend alert fatigue strategies? Sometimes teams get overwhelmed.

[44:27]Morgan Patel: Definitely. Tune your alerts to focus on high-impact events. Use dashboards to visualize trends, and regularly review alert rules to reduce noise.

[44:45]Hovhannes: Let’s do a quick pros and cons—static code scanning versus manual review for security. Where do you stand?

[44:59]Morgan Patel: Static scanning is fast and catches low-hanging fruit, but it misses context-specific issues. Manual review is slower but can spot logic flaws and unsafe patterns. You really need both.

[45:19]Hovhannes: If you had to prioritize one investment for a growing backend team—what would it be?

[45:31]Morgan Patel: Automated secrets scanning. It’s the fastest way to catch easy mistakes that lead to major breaches.

[45:48]Hovhannes: Let’s get practical—can you walk through your personal backend security checklist?

[46:05]Morgan Patel: Sure. Here’s what I check: 1) Secrets aren’t in code or logs. 2) Dependencies are pinned and scanned. 3) Auth tokens are short-lived and revocable. 4) No debug endpoints in production. 5) Access logs are enabled and monitored. 6) RBAC is enforced. 7) Safe error messages. 8) Automated CI checks for new vulnerabilities.

[46:31]Hovhannes: That’s a solid list. Let’s break those down a bit for listeners. For example, how do you make sure secrets aren’t leaking into logs?

[46:46]Morgan Patel: You can use log scrubbing middleware, and make sure your logging library lets you blacklist sensitive fields. Also, review your log output during code review.

[47:02]Hovhannes: On dependency scanning, do you automate it with every pull request, or just nightly?

[47:14]Morgan Patel: Every PR is best, so issues get caught before merging. But nightly scans are a good fallback if CI time is a concern.

[47:31]Hovhannes: For RBAC, how do you test that roles are enforced correctly?

[47:45]Morgan Patel: Write integration tests that simulate users with different roles. Try to access endpoints you shouldn’t be able to. Tools like Postman or custom scripts work well.

[48:03]Hovhannes: For error messages, what’s your go-to safe default?

[48:14]Morgan Patel: A generic 'An error occurred' for users, and detailed logs for internal tracing. Never expose stack traces or internal state to clients.

[48:30]Hovhannes: Circling back to secrets, what’s a simple way to rotate secrets with minimal downtime?

[48:43]Morgan Patel: Set up dual secrets: load both old and new in your app, switch traffic to the new one, then retire the old. This way, you can rotate without interrupting service.

[49:00]Hovhannes: We’ve covered a lot. If you had to summarize the most important mindsets for backend security, what would you say?

[49:13]Morgan Patel: Assume breach—design like attackers will find mistakes. Automate what you can, review what you can’t, and make security a shared responsibility, not just one person’s job.

[49:32]Hovhannes: Let’s move into our last segment: the implementation checklist. I’ll read out the key areas, and you give the most actionable step for each. Ready?

[49:35]Morgan Patel: Ready.

[49:37]Hovhannes: Authentication.

[49:41]Morgan Patel: Use strong, short-lived tokens and enable MFA for admin access.

[49:44]Hovhannes: Secrets management.

[49:48]Morgan Patel: Store secrets in a managed vault, never in code or config files.

[49:51]Hovhannes: Supply chain.

[49:55]Morgan Patel: Pin dependency versions and automate vulnerability scanning.

[49:58]Hovhannes: Safe defaults.

[50:03]Morgan Patel: Disable debug endpoints, use restrictive CORS, and strip verbose errors in production.

[50:06]Hovhannes: Monitoring.

[50:10]Morgan Patel: Set up alerts for authentication anomalies and new dependency introductions.

[50:13]Hovhannes: Incident response.

[50:18]Morgan Patel: Have a playbook: rotate secrets, audit logs, and communicate quickly.

[50:22]Hovhannes: Perfect. Before we wrap—any last advice for backend teams looking to level up their security?

[50:34]Morgan Patel: Don’t try to do everything at once. Pick one area, improve it, and build from there. And always make time for post-mortems to actually learn from incidents.

[50:48]Hovhannes: Love that. Okay, let’s do a quick recap checklist for listeners before we sign off. Here’s what we covered today:

[50:53]Hovhannes: - Audit and rotate secrets regularly

[50:57]Hovhannes: - Use dependency scanning and lockfiles

[51:01]Hovhannes: - Enforce strong authentication and RBAC

[51:05]Hovhannes: - Disable debug endpoints and verbose error messages in production

[51:09]Hovhannes: - Monitor logs for abnormal activity

[51:14]Hovhannes: - Have an incident response plan

[51:18]Morgan Patel: And always make security part of your code and deployment reviews, not just something you tack on at the end.

[51:29]Hovhannes: Thank you so much for joining and sharing so many practical insights. Where can folks find more of your work?

[51:41]Morgan Patel: I post tips and stories on my blog and occasionally on social media. I’m always happy to answer questions from teams looking to improve their backend security.

[51:53]Hovhannes: Amazing. We’ll link those in the episode notes. Final question: What’s one thing you wish every backend engineer would start doing tomorrow?

[52:02]Morgan Patel: Honestly? Review what’s in your environment variables—and rotate anything you can’t account for.

[52:10]Hovhannes: That’s a great takeaway. Thanks again for coming on. Any final thoughts before we wrap up?

[52:22]Morgan Patel: Just remember: attackers only need one mistake. Defenders have to get it right every time. But with good habits, you can make it a lot harder for the bad guys.

[52:36]Hovhannes: Couldn’t agree more. That’s it for this episode of Softaims. To our listeners—if you enjoyed this, please subscribe and share it with your team. If you have questions or want us to cover other security topics, send us a note.

[52:53]Hovhannes: We’ll leave you with one last checklist—these are the must-dos for backend security. Ready?

[52:55]Morgan Patel: Let’s do it.

[52:58]Hovhannes: 1. Harden authentication—use strong passwords, enable MFA, and invalidate tokens on password changes.

[53:06]Hovhannes: 2. Store secrets securely—prefer managed vaults, rotate often, and monitor access.

[53:13]Hovhannes: 3. Pin and scan dependencies—use lockfiles and automated tools.

[53:19]Hovhannes: 4. Disable debug and verbose error messages in production.

[53:24]Hovhannes: 5. Monitor for unusual activity—and actually look at your logs.

[53:29]Hovhannes: 6. Have a real incident response plan.

[53:34]Morgan Patel: And remember—security isn’t a one-time thing. It’s a habit.

[53:40]Hovhannes: Thanks again for listening to Softaims. Stay safe, stay curious, and we’ll see you in the next one.

[53:45]Morgan Patel: Thanks for having me. Take care, everyone.

[53:49]Hovhannes: Signing off. Goodbye!

[53:52]Hovhannes: (music outro)

[54:02]Hovhannes: You’ve been listening to Softaims. For more resources and episodes, visit our website. Until next time!

[55:00]Hovhannes: (episode ends)